[openstack-dev] [Quantum] security groups now enforced w/devstack
Yoshihiro Kaneko
ykaneko0929 at gmail.com
Thu Sep 20 09:41:27 UTC 2012
Hi Akihiro,
2012/9/20 Akihiro MOTOKI <amotoki at gmail.com>:
> Hi Yoshihiro,
>
> Thank for testing.
> Have you already filed a bug for this problem? If not yet, could you
> file it as a nova bug?
> It is a "folsom-rc-potential" bug and needs to be fixed I think.
Sure, will do.
>
> Thanks,
>
> 2012/9/20 Yoshihiro Kaneko <ykaneko0929 at gmail.com>:
>> 2012/9/20 Akihiro MOTOKI <motoki at da.jp.nec.com>:
>>> Hi Dan, Yoshihiro,
>>>
>>> I investigated the problem Yoshihiro reported more.
>>>
>>> When nova-compute launches an instance on KVM, vif driver plug() is called
>>> twice
>>> accorrding to the nova-compute log [1].
>>>
>>> LibvirtHybridOVSBridgeDriver plug() calles
>>> nova.network.linux_net._create_veth_pair()
>>> to create veth pair. _create_veth_pair() checks whether the specified device
>>> exists
>>> and in case the device exists it first deletes the device and (re)creates
>>> it.
>>> It may be a cause of the problem.
>>>
>>> After the following change [2], this problem seems to be addressed.
>>> If this direction is OK, I will post a patch to gerrit.
>>>
>>>> Yoshihiro,
>>> Could you test my patch on your environment?
>>
>> Great!
>> qvo was listed in brctl show and ovs-ofctl show and VM obtained an IP
>> address by DHCP.
>>
>> $ sudo ovs-vsctl show
>> 6d7929f6-8b09-41bc-b775-1ef50915eb7b
>> Bridge br-int
>> Port "tap94dddc19-c7"
>> tag: 1
>> Interface "tap94dddc19-c7"
>> type: internal
>> Port "qvo4307567c-49"
>> tag: 1
>> Interface "qvo4307567c-49"
>> Port "qr-56b7fd42-93"
>> tag: 1
>> Interface "qr-56b7fd42-93"
>> type: internal
>> Port br-int
>> Interface br-int
>> type: internal
>> Bridge br-ex
>> Port br-ex
>> Interface br-ex
>> type: internal
>> Port "eth1"
>> Interface "eth1"
>> Port "qg-e399dae7-66"
>> Interface "qg-e399dae7-66"
>> type: internal
>> ovs_version: "1.4.0+build0"
>> $ brctl show
>> bridge name bridge id STP enabled interfaces
>> br-ex 0000.ae454d673043 no qg-e399dae7-66
>> br-int 0000.a6c5c5495143 no qr-56b7fd42-93
>> qvo4307567c-49
>> tap94dddc19-c7
>> qbr4307567c-49 8000.3ab31e81960e no qvb4307567c-49
>> vnet0
>> virbr0 8000.000000000000 yes
>> virbr1 8000.525400d8a792 yes virbr1-nic
>> $ sudo ovs-ofctl show br-int
>> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000a6c5c5495143
>> n_tables:255, n_buffers:256
>> features: capabilities:0xc7, actions:0xfff
>> 1(tap94dddc19-c7): addr:78:00:00:00:00:00
>> config: PORT_DOWN
>> state: LINK_DOWN
>> 2(qr-56b7fd42-93): addr:78:00:00:00:00:00
>> config: PORT_DOWN
>> state: LINK_DOWN
>> 3(qvo4307567c-49): addr:fe:9f:c2:68:9b:7a
>> config: 0
>> state: 0
>> current: 10GB-FD COPPER
>> LOCAL(br-int): addr:a6:c5:c5:49:51:43
>> config: PORT_DOWN
>> state: LINK_DOWN
>> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
>>
>> Thanks,
>> Kaneko
>>
>>>
>>> [1]
>>> $ grep "qvo612b2502-6e" ~/logs/screen-n-cpu.log | grep ^Running
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> show dev qvo612b2502-6e
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> add qvb612b2502-6e type veth peer name qvo612b2502-6e
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> set qvo612b2502-6e up
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> set qvo612b2502-6e promisc on
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf
>>> ovs-vsctl -- --may-exist add-port br-int qvo612b2502-6e -- set Interface
>>> qvo612b2502-6e external-ids:iface-id=612b2502-6e8c-4a78-aedd-c5cb08738564
>>> external-ids:iface-status=active external-ids:attached-mac=fa:16:3e:97:e4:aa
>>> external-ids:vm-uuid=f0321c00-8ef0-4a18-9921-8452236877f2
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> show dev qvo612b2502-6e
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> add qvb612b2502-6e type veth peer name qvo612b2502-6e
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> set qvo612b2502-6e up
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf ip link
>>> set qvo612b2502-6e promisc on
>>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf
>>> ovs-vsctl -- --may-exist add-port br-int qvo612b2502-6e -- set Interface
>>> qvo612b2502-6e external-ids:iface-id=612b2502-6e8c-4a78-aedd-c5cb08738564
>>> external-ids:iface-status=active external-ids:attached-mac=fa:16:3e:97:e4:aa
>>> external-ids:vm-uuid=f0321c00-8ef0-4a18-9921-8452236877f2
>>>
>>> [2]
>>> diff --git a/nova/virt/libvirt/vif.py b/nova/virt/libvirt/vif.py
>>> index 1a64765..ea0834d 100644
>>> --- a/nova/virt/libvirt/vif.py
>>> +++ b/nova/virt/libvirt/vif.py
>>> @@ -212,15 +212,15 @@ class
>>> LibvirtHybridOVSBridgeDriver(LibvirtBridgeDriver,
>>> br_name = self.get_br_name(iface_id)
>>> v1_name, v2_name = self.get_veth_pair_names(iface_id)
>>>
>>> - linux_net._create_veth_pair(v1_name, v2_name)
>>> -
>>> if not linux_net._device_exists(br_name):
>>> utils.execute('brctl', 'addbr', br_name, run_as_root=True)
>>>
>>> - utils.execute('ip', 'link', 'set', br_name, 'up', run_as_root=True)
>>> - utils.execute('brctl', 'addif', br_name, v1_name, run_as_root=True)
>>> - self.create_ovs_vif_port(v2_name, iface_id, mapping['mac'],
>>> - instance['uuid'])
>>> + if not linux_net._device_exists(v2_name):
>>> + linux_net._create_veth_pair(v1_name, v2_name)
>>> + utils.execute('ip', 'link', 'set', br_name, 'up',
>>> run_as_root=True)
>>> + utils.execute('brctl', 'addif', br_name, v1_name,
>>> run_as_root=True)
>>> + self.create_ovs_vif_port(v2_name, iface_id, mapping['mac'],
>>> + instance['uuid'])
>>>
>>> network['bridge'] = br_name
>>> return self._get_configurations(instance, network, mapping)
>>>
>>>
>>> (2012/09/20 13:13), Yoshihiro Kaneko wrote:
>>>>
>>>> Has nobody encountered this problem? Only me?
>>>> I will try this in other fresh environment.
>>>>
>>>> Kaneko
>>>>
>>>> 2012/9/19 Yoshihiro Kaneko <ykaneko0929 at gmail.com>:
>>>>>
>>>>> I found that qvo was not "internal". Therefore I set "type=internal"
>>>>> to qvo manually.
>>>>> As a result, qvo appeared in the output of "brctl show" and VM was
>>>>> able to obtain
>>>>> IP address by DHCP.
>>>>> Is this correct?
>>>>>
>>>>> Before set interface type
>>>>> ----------
>>>>> $ sudo ovs-vsctl show
>>>>> 6d7929f6-8b09-41bc-b775-1ef50915eb7b
>>>>> Bridge br-int
>>>>> Port "tap8c462a80-f6"
>>>>> tag: 1
>>>>> Interface "tap8c462a80-f6"
>>>>> type: internal
>>>>> Port "qvo076911a5-59"
>>>>> tag: 1
>>>>> Interface "qvo076911a5-59"
>>>>> Port br-int
>>>>> Interface br-int
>>>>> type: internal
>>>>> Port "qr-6dd16ab9-d6"
>>>>> tag: 1
>>>>> Interface "qr-6dd16ab9-d6"
>>>>> type: internal
>>>>> Bridge br-ex
>>>>> Port br-ex
>>>>> Interface br-ex
>>>>> type: internal
>>>>> Port "qg-de1db666-3d"
>>>>> Interface "qg-de1db666-3d"
>>>>> type: internal
>>>>> Port "eth1"
>>>>> Interface "eth1"
>>>>> ovs_version: "1.4.0+build0"
>>>>> $ brctl show
>>>>> bridge name bridge id STP enabled interfaces
>>>>> br-ex 0000.ae454d673043 no qg-de1db666-3d
>>>>> br-int 0000.c6d8e9064848 no qr-6dd16ab9-d6
>>>>> tap8c462a80-f6
>>>>> qbr076911a5-59 8000.26397c9d0d15 no
>>>>> qvb076911a5-59
>>>>> vnet0
>>>>> virbr0 8000.000000000000 yes
>>>>> virbr1 8000.525400d8a792 yes virbr1-nic
>>>>> ----------
>>>>>
>>>>> Set interface type to qvo
>>>>> ----------
>>>>> $ sudo ovs-vsctl set Interface qvo076911a5-59 type=internal
>>>>> $ sudo ovs-vsctl show
>>>>> 6d7929f6-8b09-41bc-b775-1ef50915eb7b
>>>>> Bridge br-int
>>>>> Port "tap8c462a80-f6"
>>>>> tag: 1
>>>>> Interface "tap8c462a80-f6"
>>>>> type: internal
>>>>> Port "qvo076911a5-59"
>>>>> tag: 1
>>>>> Interface "qvo076911a5-59"
>>>>> type: internal
>>>>> Port br-int
>>>>> Interface br-int
>>>>> type: internal
>>>>> Port "qr-6dd16ab9-d6"
>>>>> tag: 1
>>>>> Interface "qr-6dd16ab9-d6"
>>>>> type: internal
>>>>> Bridge br-ex
>>>>> Port br-ex
>>>>> Interface br-ex
>>>>> type: internal
>>>>> Port "qg-de1db666-3d"
>>>>> Interface "qg-de1db666-3d"
>>>>> type: internal
>>>>> Port "eth1"
>>>>> Interface "eth1"
>>>>> ovs_version: "1.4.0+build0"
>>>>> $ brctl show
>>>>> bridge name bridge id STP enabled interfaces
>>>>> br-ex 0000.ae454d673043 no qg-de1db666-3d
>>>>> br-int 0000.c6d8e9064848 no qr-6dd16ab9-d6
>>>>> qvo076911a5-59
>>>>> tap8c462a80-f6
>>>>> qbr076911a5-59 8000.26397c9d0d15 no
>>>>> qvb076911a5-59
>>>>> vnet0
>>>>> virbr0 8000.000000000000 yes
>>>>> virbr1 8000.525400d8a792 yes virbr1-nic
>>>>> ----------
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kaneko
>>>>>
>>>>> 2012/9/19 Yoshihiro Kaneko <ykaneko0929 at gmail.com>:
>>>>>>
>>>>>> I re-added qvo to br-int manually, then it appeared in the output of
>>>>>> "brctl show".
>>>>>> And VM was able to obtain an IP address by DHCP.
>>>>>> What I did is as follows.
>>>>>> sudo ovs-vsctl del-port qvoXXXX
>>>>>> sudo ovs-vsctl add-port br-int qvoXXXX
>>>>>> sudo ovs-vsctl set port qvoXXXX tag=1
>>>>>>
>>>>>> I restarted devstack without re-add qvo, the problem was reproduced.
>>>>>> VM could not obtain IP address from DHCP server.
>>>>>>
>>>>>> And I re-added qvo manually again. In this time, I did a thing same as
>>>>>> vif-driver recorded in a syslog. Then, VM obtains an IP address by DHCP
>>>>>> again.
>>>>>>
>>>>>> sudo ovs-vsctl del-port qvoXXXX
>>>>>> sudo ovs-vsctl -- --may-exist add-port br-int qvoXXX -- set Interface
>>>>>> qvoXXXX
>>>>>> external-ids:iface-id=XXXX external-ids:iface-status=active
>>>>>> external-ids:attached-mac=XXXX external-ids:vm-uuid=XXXX
>>>>>> (VLAN tag was added automatically)
>>>>>>
>>>>>> What should I do next?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Kaneko
>>>>>>
>>>>>> 2012/9/18 Yoshihiro Kaneko <ykaneko0929 at gmail.com>:
>>>>>>>
>>>>>>> 2012/9/18 Dan Wendlandt <dan at nicira.com>:
>>>>>>>>
>>>>>>>> On Mon, Sep 17, 2012 at 11:12 PM, Yoshihiro Kaneko
>>>>>>>> <ykaneko0929 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Dan,
>>>>>>>>>
>>>>>>>>> Thanks for the reply.
>>>>>>>>>
>>>>>>>>> This is the result of "brctl show".
>>>>>>>>> ----------
>>>>>>>>> $ brctl show
>>>>>>>>> bridge name bridge id STP enabled interfaces
>>>>>>>>> br-ex 0000.6e47647aee44 no
>>>>>>>>> qg-8c3a652b-f1
>>>>>>>>> br-int 0000.4af0ded34a40 no
>>>>>>>>> qr-f9a49be5-c1
>>>>>>>>>
>>>>>>>>> tap5a418ee0-53
>>>>>>>>> qbr99eea189-fc 8000.5e15f4c7d4f2 no
>>>>>>>>> qvb99eea189-fc
>>>>>>>>> vnet0
>>>>>>>>> virbr0 8000.000000000000 yes
>>>>>>>>> virbr1 8000.525400d8a792 yes virbr1-nic
>>>>>>>>
>>>>>>>>
>>>>>>>> can you send the output of
>>>>>>>>
>>>>>>>> ovs-vsctl list-ports br-int (or ovs-vsctl show)?
>>>>>>>>
>>>>>>>> Its odd that the above output does not include qvo99eea189-fc, which
>>>>>>>> should be attached to br-int.
>>>>>>>
>>>>>>>
>>>>>>> This is the output. I restarted devstack, so the interface name is
>>>>>>> different from above.
>>>>>>> There is not "qvo" in the output of "brctl show". But it exists in
>>>>>>> "ovs-vsctl list-ports br-int"
>>>>>>> (and "ovs-vsctl show"). And not found in "ovs-dpctl show br-int".
>>>>>>>
>>>>>>> ----------
>>>>>>> $ sudo brctl show
>>>>>>> bridge name bridge id STP enabled interfaces
>>>>>>> br-ex 0000.2a93351db24b no qg-669c94f9-41
>>>>>>> br-int 0000.363636554a4e no qr-185216c4-b7
>>>>>>> tap4061a128-21
>>>>>>> qbra5838945-25 8000.d639643f11ef no
>>>>>>> qvba5838945-25
>>>>>>> vnet0
>>>>>>> virbr0 8000.000000000000 yes
>>>>>>> virbr1 8000.525400d8a792 yes virbr1-nic
>>>>>>> $
>>>>>>>
>>>>>>> $ sudo ovs-vsctl list-ports br-int
>>>>>>> qr-185216c4-b7
>>>>>>> qvoa5838945-25
>>>>>>> tap4061a128-21
>>>>>>> $
>>>>>>> $ sudo ovs-dpctl show br-int
>>>>>>> system at br-int:
>>>>>>> lookups: hit:7 missed:14 lost:0
>>>>>>> flows: 0
>>>>>>> port 0: br-int (internal)
>>>>>>> Sep 18
>>>>>>> 16:35:45|00001|netdev_linux|WARN|/sys/class/net/tap4061a128-21/carrier:
>>>>>>> open failed: No such file or directory
>>>>>>> port 1: tap4061a128-21 (internal)
>>>>>>> Sep 18
>>>>>>> 16:35:45|00002|netdev_linux|WARN|/sys/class/net/qr-185216c4-b7/carrier:
>>>>>>> open failed: No such file or directory
>>>>>>> port 2: qr-185216c4-b7 (internal)
>>>>>>> ----------
>>>>>>>
>>>>>>> Kaneko
>>>>>>>
>>>>>>>>
>>>>>>>> dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> ----------
>>>>>>>>>
>>>>>>>>> Following is the result that was running tcpdump on each terminal
>>>>>>>>> concurrently.
>>>>>>>>> I don't know why each DHCP packet was received twice on vnet0. And
>>>>>>>>> the tap
>>>>>>>>> device used by dnsmasq did not receive udp packet in qdhcp-
>>>>>>>>> namespace.
>>>>>>>>> ----------
>>>>>>>>> # tcpdump -ni vnet0 udp
>>>>>>>>> tcpdump: WARNING: vnet0: no IPv4 address assigned
>>>>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>>>>>> decode
>>>>>>>>> listening on vnet0, link-type EN10MB (Ethernet), capture size 65535
>>>>>>>>> bytes
>>>>>>>>> 12:00:56.619340 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:00:56.619423 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:00:59.624796 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:00:59.624858 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:01:02.630474 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:01:02.630564 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>>
>>>>>>>>> # tcpdump -ni qvb99eea189-fc udp
>>>>>>>>> tcpdump: WARNING: qvb99eea189-fc: no IPv4 address assigned
>>>>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>>>>>> decode
>>>>>>>>> listening on qvb99eea189-fc, link-type EN10MB (Ethernet), capture
>>>>>>>>> size
>>>>>>>>> 65535 bytes
>>>>>>>>> 12:00:56.619436 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:00:59.624872 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:01:02.630586 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>>
>>>>>>>>> # tcpdump -ni qvo99eea189-fc udp
>>>>>>>>> tcpdump: WARNING: qvo99eea189-fc: no IPv4 address assigned
>>>>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>>>>>> decode
>>>>>>>>> listening on qvo99eea189-fc, link-type EN10MB (Ethernet), capture
>>>>>>>>> size
>>>>>>>>> 65535 bytes
>>>>>>>>> 12:00:56.619467 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:00:59.624904 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>> 12:01:02.630633 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>>>>>>>>> Request from fa:16:3e:48:aa:85, length 280
>>>>>>>>>
>>>>>>>>> # tcpdump -ni tap5a418ee0-53 udp
>>>>>>>>> tcpdump: tap5a418ee0-53: No such device exists
>>>>>>>>> (SIOCGIFHWADDR: No such device)
>>>>>>>>> # ip netns exec qdhcp-c95edcb8-3df6-4e92-a367-4fce5bce6e63 tcpdump
>>>>>>>>> -ni
>>>>>>>>> tap5a418ee0-53 udp
>>>>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>>>>>> decode
>>>>>>>>> listening on tap5a418ee0-53, link-type EN10MB (Ethernet), capture
>>>>>>>>> size
>>>>>>>>> 65535 bytes
>>>>>>>>> ----------
>>>>>>>>>
>>>>>>>>> When using
>>>>>>>>> "libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtOpenVswitchDriver",
>>>>>>>>> VM can obtain an IP address by DHCP.
>>>>>>>>> ----------
>>>>>>>>> $ grep libvirt_vif_driver /etc/nova/nova.conf
>>>>>>>>> libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtOpenVswitchDriver
>>>>>>>>> $ nova console-log vm1
>>>>>>>>> <snip>
>>>>>>>>> Starting network...
>>>>>>>>> udhcpc (v1.18.5) started
>>>>>>>>> Sending discover...
>>>>>>>>> Sending select for 10.0.0.3...
>>>>>>>>> Lease of 10.0.0.3 obtained, lease time 120
>>>>>>>>> deleting routers
>>>>>>>>> route: SIOCDELRT: No such process
>>>>>>>>> adding dns 10.0.0.2
>>>>>>>>> <snip>
>>>>>>>>> ----------
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Kaneko
>>>>>>>>>
>>>>>>>>> 2012/9/17 Dan Wendlandt <dan at nicira.com>:
>>>>>>>>>>
>>>>>>>>>> Hi Kaneko,
>>>>>>>>>>
>>>>>>>>>> Thanks for the detailed report. At a glance, things look correct.
>>>>>>>>>>
>>>>>>>>>> I'd suggest running tcpdump on various interfaces to figure how far
>>>>>>>>>> the DHCP requests/responses are reaching.
>>>>>>>>>>
>>>>>>>>>> tcpdump -ni vnetX udp (replace vnetX with correct device... can't
>>>>>>>>>> tell
>>>>>>>>>> from your output. try running brctl show).
>>>>>>>>>>
>>>>>>>>>> tcpdump -ni qvb99eea189-fc udp (veth device on VIF-specific
>>>>>>>>>> bridge)
>>>>>>>>>>
>>>>>>>>>> tcpdump -ni qvo99eea189-fc udp (veth device on main OVS bridge)
>>>>>>>>>>
>>>>>>>>>> tcpdump -ni tap5a418ee0-53 udp (tap device used by dnsmasq)
>>>>>>>>>>
>>>>>>>>>> Another interesting data point would be whether you only see these
>>>>>>>>>> issues when using
>>>>>>>>>>
>>>>>>>>>> "libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver",
>>>>>>>>>> or whether you also see it with
>>>>>>>>>> "libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtOpenVswitchDriver
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 14, 2012 at 3:13 AM, Yoshihiro Kaneko
>>>>>>>>>> <ykaneko0929 at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>
>>>>>>>>>>> I tried it on Ubuntu 12.04. However VM could not obtain an IP
>>>>>>>>>>> address from
>>>>>>>>>>> a DHCP server.
>>>>>>>>>>> Any advice?
>>>>>>>>>>> If more information is needed, please let me know.
>>>>>>>>>>>
>>>>>>>>>>> $ git clone git://github.com/openstack-dev/devstack
>>>>>>>>>>> Cloning into 'devstack'...
>>>>>>>>>>> remote: Counting objects: 6415, done.
>>>>>>>>>>> remote: Compressing objects: 100% (2186/2186), done.
>>>>>>>>>>> remote: Total 6415 (delta 4352), reused 6145 (delta 4151)
>>>>>>>>>>> Receiving objects: 100% (6415/6415), 1.10 MiB | 470 KiB/s, done.
>>>>>>>>>>> Resolving deltas: 100% (4352/4352), done.
>>>>>>>>>>> $ cd devstack/
>>>>>>>>>>> $ git fetch https://review.openstack.org/openstack-dev/devstack
>>>>>>>>>>> refs/changes/50/11650/8 && git checkout FETCH_HEAD
>>>>>>>>>>> remote: Counting objects: 5, done
>>>>>>>>>>> remote: Finding sources: 100% (3/3)
>>>>>>>>>>> remote: Total 3 (delta 2), reused 3 (delta 2)
>>>>>>>>>>> Unpacking objects: 100% (3/3), done.
>>>>>>>>>>> From https://review.openstack.org/openstack-dev/devstack
>>>>>>>>>>> * branch refs/changes/50/11650/8 -> FETCH_HEAD
>>>>>>>>>>> Note: checking out 'FETCH_HEAD'.
>>>>>>>>>>>
>>>>>>>>>>> You are in 'detached HEAD' state. You can look around, make
>>>>>>>>>>> experimental
>>>>>>>>>>> changes and commit them, and you can discard any commits you make
>>>>>>>>>>> in this
>>>>>>>>>>> state without impacting any branches by performing another
>>>>>>>>>>> checkout.
>>>>>>>>>>>
>>>>>>>>>>> If you want to create a new branch to retain commits you create,
>>>>>>>>>>> you may
>>>>>>>>>>> do so (now or later) by using -b with the checkout command again.
>>>>>>>>>>> Example:
>>>>>>>>>>>
>>>>>>>>>>> git checkout -b new_branch_name
>>>>>>>>>>>
>>>>>>>>>>> HEAD is now at cea6c51... Quantum enhancements
>>>>>>>>>>> $ vi localrc
>>>>>>>>>>> $ cat localrc
>>>>>>>>>>> disable_service n-net
>>>>>>>>>>> enable_service q-svc q-agt q-dhcp q-l3 quantum
>>>>>>>>>>>
>>>>>>>>>>> $ cp samples/local.sh .
>>>>>>>>>>> $ ./stack.sh
>>>>>>>>>>> <snip>
>>>>>>>>>>> $ . ./openrc demo demo
>>>>>>>>>>> $ nova image-list
>>>>>>>>>>> <snip>
>>>>>>>>>>> $ quantum net-list
>>>>>>>>>>> <snip>
>>>>>>>>>>> $ nova boot --flavor 6 --image 7777d0ed-294c-4634-9304-769f64a52c81
>>>>>>>>>>> --nic net-id=c95edcb8-3df6-4e92-a367-4fce5bce6e63 vm1
>>>>>>>>>>> <snip>
>>>>>>>>>>> $ nova list
>>>>>>>>>>>
>>>>>>>>>>> +--------------------------------------+------+--------+---------------+
>>>>>>>>>>> | ID | Name | Status | Networks
>>>>>>>>>>> |
>>>>>>>>>>>
>>>>>>>>>>> +--------------------------------------+------+--------+---------------+
>>>>>>>>>>> | 723d76c4-4dea-4fe4-a4d8-6ca8d08bb936 | vm1 | ACTIVE |
>>>>>>>>>>> net1=10.0.0.3 |
>>>>>>>>>>>
>>>>>>>>>>> +--------------------------------------+------+--------+---------------+
>>>>>>>>>>> $ nova console-log vm1
>>>>>>>>>>> <snip>
>>>>>>>>>>> Starting network...
>>>>>>>>>>> udhcpc (v1.18.5) started
>>>>>>>>>>> Sending discover...
>>>>>>>>>>> Sending discover...
>>>>>>>>>>> Sending discover...
>>>>>>>>>>> No lease, failing
>>>>>>>>>>> WARN: /etc/rc3.d/S40-network failed
>>>>>>>>>>> <snip>
>>>>>>>>>>>
>>>>>>>>>>> $ sudo ovs-vsctl show
>>>>>>>>>>> 6d7929f6-8b09-41bc-b775-1ef50915eb7b
>>>>>>>>>>> Bridge br-ex
>>>>>>>>>>> Port "qg-8c3a652b-f1"
>>>>>>>>>>> Interface "qg-8c3a652b-f1"
>>>>>>>>>>> type: internal
>>>>>>>>>>> Port br-ex
>>>>>>>>>>> Interface br-ex
>>>>>>>>>>> type: internal
>>>>>>>>>>> Bridge br-int
>>>>>>>>>>> Port "tap5a418ee0-53"
>>>>>>>>>>> tag: 1
>>>>>>>>>>> Interface "tap5a418ee0-53"
>>>>>>>>>>> type: internal
>>>>>>>>>>> Port "qr-f9a49be5-c1"
>>>>>>>>>>> tag: 1
>>>>>>>>>>> Interface "qr-f9a49be5-c1"
>>>>>>>>>>> type: internal
>>>>>>>>>>> Port "qvo99eea189-fc"
>>>>>>>>>>> tag: 1
>>>>>>>>>>> Interface "qvo99eea189-fc"
>>>>>>>>>>> Port br-int
>>>>>>>>>>> Interface br-int
>>>>>>>>>>> type: internal
>>>>>>>>>>> ovs_version: "1.4.0+build0"
>>>>>>>>>>>
>>>>>>>>>>> $ ip netns
>>>>>>>>>>> qrouter-aed60aac-288b-41ee-bc4a-9ed5a356a16d
>>>>>>>>>>> qdhcp-c95edcb8-3df6-4e92-a367-4fce5bce6e63
>>>>>>>>>>>
>>>>>>>>>>> $ ps ax|grep dnsmasq
>>>>>>>>>>> 6107 ? S 0:00 dnsmasq --no-hosts --no-resolv
>>>>>>>>>>> --strict-order --bind-interfaces --interface=tap5a418ee0-53
>>>>>>>>>>> --except-interface=lo --domain=openstacklocal
>>>>>>>>>>>
>>>>>>>>>>> --pid-file=/opt/stack/data/dhcp/c95edcb8-3df6-4e92-a367-4fce5bce6e63/pid
>>>>>>>>>>>
>>>>>>>>>>> --dhcp-hostsfile=/opt/stack/data/dhcp/c95edcb8-3df6-4e92-a367-4fce5bce6e63/host
>>>>>>>>>>>
>>>>>>>>>>> --dhcp-optsfile=/opt/stack/data/dhcp/c95edcb8-3df6-4e92-a367-4fce5bce6e63/opts
>>>>>>>>>>>
>>>>>>>>>>> --dhcp-script=/opt/stack/quantum/bin/quantum-dhcp-agent-dnsmasq-lease-update
>>>>>>>>>>> --leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,120s
>>>>>>>>>>> 6108 ? S 0:00 dnsmasq --no-hosts --no-resolv
>>>>>>>>>>> --strict-order --bind-interfaces --interface=tap5a418ee0-53
>>>>>>>>>>> --except-interface=lo --domain=openstacklocal
>>>>>>>>>>>
>>>>>>>>>>> --pid-file=/opt/stack/data/dhcp/c95edcb8-3df6-4e92-a367-4fce5bce6e63/pid
>>>>>>>>>>>
>>>>>>>>>>> --dhcp-hostsfile=/opt/stack/data/dhcp/c95edcb8-3df6-4e92-a367-4fce5bce6e63/host
>>>>>>>>>>>
>>>>>>>>>>> --dhcp-optsfile=/opt/stack/data/dhcp/c95edcb8-3df6-4e92-a367-4fce5bce6e63/opts
>>>>>>>>>>>
>>>>>>>>>>> --dhcp-script=/opt/stack/quantum/bin/quantum-dhcp-agent-dnsmasq-lease-update
>>>>>>>>>>> --leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,120s
>>>>>>>>>>> 28913 pts/1 S+ 0:00 grep --color=auto dnsmasq
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Kaneko
>>>>>>>>>>>
>>>>>>>>>>> 2012/9/14 Dan Wendlandt <dan at nicira.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi quantum hackers,
>>>>>>>>>>>>
>>>>>>>>>>>> We're pushing a change to devstack to use a new vif-driver for
>>>>>>>>>>>> Quantum
>>>>>>>>>>>> with Open vSwitch (https://review.openstack.org/#/c/11650/). The
>>>>>>>>>>>> benefit of this driver is that it is compatible with Nova's
>>>>>>>>>>>> security
>>>>>>>>>>>> group filtering. This is "a good thing", since it more closely
>>>>>>>>>>>> maps
>>>>>>>>>>>> to how real users will deploy Quantum.
>>>>>>>>>>>>
>>>>>>>>>>>> However, this may catch developers by surprise who are suddenly
>>>>>>>>>>>> unable
>>>>>>>>>>>> to ping or SSH to instances because the security groups drop
>>>>>>>>>>>> traffic
>>>>>>>>>>>> by default.
>>>>>>>>>>>>
>>>>>>>>>>>> Preferred method of dealing with this is to add the following
>>>>>>>>>>>> lines to
>>>>>>>>>>>> local.sh in your devstack directory, which open up your VMs for
>>>>>>>>>>>> ping
>>>>>>>>>>>> and SSH for the 'demo' user:
>>>>>>>>>>>>
>>>>>>>>>>>> nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
>>>>>>>>>>>> nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
>>>>>>>>>>>>
>>>>>>>>>>>> Another work around is to disable nova security groups by adding
>>>>>>>>>>>> 'LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver' to
>>>>>>>>>>>> your localrc
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>>> Dan Wendlandt
>>>>>>>>>>>> Nicira, Inc: www.nicira.com
>>>>>>>>>>>> twitter: danwendlandt
>>>>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>> Dan Wendlandt
>>>>>>>>>> Nicira, Inc: www.nicira.com
>>>>>>>>>> twitter: danwendlandt
>>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>> Dan Wendlandt
>>>>>>>> Nicira, Inc: www.nicira.com
>>>>>>>> twitter: danwendlandt
>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Akihiro MOTOKI <amotoki at gmail.com>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list