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

Yoshihiro Kaneko ykaneko0929 at gmail.com
Thu Sep 20 09:05:02 UTC 2012


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



More information about the OpenStack-dev mailing list