[openstack-dev] [Quantum] security groups now enforced w/devstack

Akihiro MOTOKI amotoki at gmail.com
Thu Sep 20 09:21:12 UTC 2012


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.

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>



More information about the OpenStack-dev mailing list