[Openstack-operators] OpenStack-operators Digest, Vol 35, Issue 1
yungho
yungho5054 at gmail.com
Tue Sep 3 02:51:57 UTC 2013
Hello,
I CentOs6.4 environment to deploy OpenStack G version, Controller
Node, Network Node, Compute Node. Networks using Qauntum, but is still on
the Quantum network model do not know, and want to know under what
circumstances the use of gre, under what circumstances the vlan mode.
On Tue, Sep 3, 2013 at 8:44 AM, <
openstack-operators-request at lists.openstack.org> wrote:
> Send OpenStack-operators mailing list submissions to
> openstack-operators at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> or, via email, send a message with subject or body 'help' to
> openstack-operators-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-operators-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-operators digest..."
>
>
> Today's Topics:
>
> 1. Quantum Security Groups not working - iptables rules are not
> Evaluated (Sebastian Porombka)
> 2. Re: Quantum Security Groups not working - iptables rules are
> not Evaluated (Darragh O'Reilly)
> 3. Running DHCP agent in HA (grizzly) (Robert van Leeuwen)
> 4. Re: Quantum Security Groups not working - iptables rules are
> not Evaluated (Lorin Hochstein)
> 5. Re: Running DHCP agent in HA (grizzly) (Simon Pasquier)
> 6. Re: Quantum Security Groups not working - iptables rules are
> not Evaluated (Darragh O'Reilly)
> 7. Migrating instances in grizzly (Juan Jos? Pavlik Salles)
> 8. Re: Quantum Security Groups not working - iptables rules are
> not Evaluated (Sebastian Porombka)
> 9. Re: Migrating instances in grizzly (Juan Jos? Pavlik Salles)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 2 Sep 2013 13:48:08 +0000
> From: Sebastian Porombka <porombka at uni-paderborn.de>
> To: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Subject: [Openstack-operators] Quantum Security Groups not working -
> iptables rules are not Evaluated
> Message-ID: <CE4A6242.49182%porombka at uni-paderborn.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi folks.
>
> We're currently on the way to deploy an openstack (grizzly) cloud
> environment
> and suffering in problems implementing the security groups like described
> in
> [1].
>
> The (hopefully) relevant configuration settings are:
>
> /etc/nova/nova.conf
> [?]
> security_group_api=quantum
> network_api_class=nova.network.quantumv2.api.API
> libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
> firewall_driver=nova.virt.firewall.NoopFirewallDriver
> [?]
>
> /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
> [?]
> firewall_driver =
> quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> [?]
>
> The Networks for the vm's are attached to the compute-nodes via VLAN
> encapsulation and correctly mapped to the vm's.
>
> >From our point of view - we're understanding the need of the
> "ovs-bridge <> veth glue <> linux-bridge (for filtering) <>
> vm"-construction
> and observed the single components in our deployment. See [2]
>
> Everything is working except the security groups.
> We observed that ip-tables rules are generated for the quantum-openvswi-*
> chains of iptables.
> And the traffic arriving untagged (native vlan for management) on the
> machine is processed by iptables but not
> the traffic which arrived encapsulated.
>
> The traffic which is unpacked by openvswitch and is bridged via the veth
> and
> the tap into
> the machine isn't processed by the iptables rules.
>
> We have no remaining clue/idea how to solve this issue? :(
>
> Greetings
> Sebastian
>
> [1]
>
> http://docs.openstack.org/trunk/openstack-network/admin/content/under_the_ho
> od_openvswitch.html
> [2] http://pastebin.com/WXMH6y4A
>
> --
> Sebastian Porombka, M.Sc.
> Zentrum f?r Informations- und Medientechnologien (IMT)
> Universit?t Paderborn
>
> E-Mail: porombka at uni-paderborn.de
> Tel.: 05251/60-5999
> Fax: 05251/60-48-5999
> Raum: N5.314
>
> --------------------------------------------
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es <http://five.sentenc.es/>
>
> Please consider the environment before printing this email.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-operators/attachments/20130902/83f01473/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5443 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-operators/attachments/20130902/83f01473/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 2 Sep 2013 15:21:10 +0100 (BST)
> From: Darragh O'Reilly <dara2002-openstack at yahoo.com>
> To: Sebastian Porombka <porombka at uni-paderborn.de>,
> "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Quantum Security Groups not working
> - iptables rules are not Evaluated
> Message-ID:
> <1378131670.96925.YahooMailNeo at web172405.mail.ir2.yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
>
> it is not working because you are using the ovs bridge compatibility
> module.
>
> Re,
> Darragh.
>
> >________________________________
> > From: Sebastian Porombka <porombka at uni-paderborn.de>
> >To: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> >Sent: Monday, 2 September 2013, 14:48
> >Subject: [Openstack-operators] Quantum Security Groups not working -
> iptables rules are not Evaluated
> >
> >
> >
> >Hi folks.
> >
> >
> >We're currently on the way to deploy an openstack (grizzly) cloud
> environment?
> >and suffering in problems implementing the security groups like described
> in [1].
> >
> >
> >The (hopefully) relevant configuration settings are:
> >
> >
> >/etc/nova/nova.conf
> >[?]
> >security_group_api=quantum
> >network_api_class=nova.network.quantumv2.api.API
> >libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
> >firewall_driver=nova.virt.firewall.NoopFirewallDriver
> >[?]
> >
> >
> >/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
> >[?]
> >firewall_driver =
> quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> >[?]
> >
> >
> >The Networks for the vm's are attached to the compute-nodes via VLAN?
> >encapsulation and correctly mapped to the vm's.
> >
> >
> >From our point of view - we're understanding the need of the?
> >"ovs-bridge <> veth glue <> linux-bridge (for filtering) <>
> vm"-construction?
> >and observed the single components in our deployment. See [2]
> >
> >
> >Everything is working except the security groups.?
> >We observed that ip-tables rules are generated for the?quantum-openvswi-*
> chains of iptables.?
> >And the traffic arriving untagged (native vlan for management) on the
> machine is processed by iptables but not?
> >the traffic which arrived encapsulated.
> >
> >
> >The traffic which is unpacked by openvswitch and is bridged via the veth
> and the tap into?
> >the machine isn't processed by the iptables rules.
> >
> >
> >We have no remaining clue/idea how to solve this issue? :(
> >
> >
> >Greetings
> >? ?Sebastian
> >
> >
> >[1]?
> http://docs.openstack.org/trunk/openstack-network/admin/content/under_the_hood_openvswitch.html
> >[2]?http://pastebin.com/WXMH6y4A
> >
> >
> >--
> >Sebastian Porombka,?M.Sc.?
> >Zentrum f?r Informations- und Medientechnologien (IMT)
> >Universit?t Paderborn
> >
> >
> >E-Mail:?porombka at uni-paderborn.de
> >Tel.: 05251/60-5999
> >Fax:?05251/60-48-5999
> >Raum: N5.314?
> >
> >
> >--------------------------------------------
> >Q: Why is this email five sentences or less?
> >A:?http://five.sentenc.es
> >
> >
> >Please consider the environment before printing this email.
> >_______________________________________________
> >OpenStack-operators mailing list
> >OpenStack-operators at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 2 Sep 2013 14:41:34 +0000
> From: Robert van Leeuwen <Robert.vanLeeuwen at spilgames.com>
> To: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Subject: [Openstack-operators] Running DHCP agent in HA (grizzly)
> Message-ID:
> <79E00D9220302D448C1D59B5224ED12D8D9C7AE1 at EchoDB02.spil.local>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> How would one make sure multiple dhcp agents run for the same segment?
> I currently have 2 dhcp agents running but only one is added to a network
> when the network is created.
>
> When I manually add the other one with "quantum dhcp-agent-network-add"
> but I would like this to happen automatically.
>
> Thx,
> Robert
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 2 Sep 2013 11:00:41 -0400
> From: Lorin Hochstein <lorin at nimbisservices.com>
> To: "Darragh O'Reilly" <dara2002-openstack at yahoo.com>
> Cc: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Quantum Security Groups not working
> - iptables rules are not Evaluated
> Message-ID:
> <
> CADzpNMXaPHQCdgjCwOJDK-fC4E6KF14K_gvr5AHnwknEwH4N8w at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Darragh:
>
> Can you elaborate on this a little more? Do you mean that the "brcompat"
> kernel module has been loaded, and this breaks security groups with the ovs
> plugin? Should we add something in the documentation about this?
>
> Lorin
>
>
> Do you mean that the problem is that the ovs-brcompatd service is running?
>
> openvswitch-brcompat package is installed?
>
>
> On Mon, Sep 2, 2013 at 10:21 AM, Darragh O'Reilly <
> dara2002-openstack at yahoo.com> wrote:
>
> >
> > it is not working because you are using the ovs bridge compatibility
> > module.
> >
> > Re,
> > Darragh.
> >
> > >________________________________
> > > From: Sebastian Porombka <porombka at uni-paderborn.de>
> > >To: "openstack-operators at lists.openstack.org" <
> > openstack-operators at lists.openstack.org>
> > >Sent: Monday, 2 September 2013, 14:48
> > >Subject: [Openstack-operators] Quantum Security Groups not working -
> > iptables rules are not Evaluated
> > >
> > >
> > >
> > >Hi folks.
> > >
> > >
> > >We're currently on the way to deploy an openstack (grizzly) cloud
> > environment
> > >and suffering in problems implementing the security groups like
> described
> > in [1].
> > >
> > >
> > >The (hopefully) relevant configuration settings are:
> > >
> > >
> > >/etc/nova/nova.conf
> > >[?]
> > >security_group_api=quantum
> > >network_api_class=nova.network.quantumv2.api.API
> > >libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
> > >firewall_driver=nova.virt.firewall.NoopFirewallDriver
> > >[?]
> > >
> > >
> > >/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
> > >[?]
> > >firewall_driver =
> > quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> > >[?]
> > >
> > >
> > >The Networks for the vm's are attached to the compute-nodes via VLAN
> > >encapsulation and correctly mapped to the vm's.
> > >
> > >
> > >From our point of view - we're understanding the need of the
> > >"ovs-bridge <> veth glue <> linux-bridge (for filtering) <>
> > vm"-construction
> > >and observed the single components in our deployment. See [2]
> > >
> > >
> > >Everything is working except the security groups.
> > >We observed that ip-tables rules are generated for the
> quantum-openvswi-*
> > chains of iptables.
> > >And the traffic arriving untagged (native vlan for management) on the
> > machine is processed by iptables but not
> > >the traffic which arrived encapsulated.
> > >
> > >
> > >The traffic which is unpacked by openvswitch and is bridged via the veth
> > and the tap into
> > >the machine isn't processed by the iptables rules.
> > >
> > >
> > >We have no remaining clue/idea how to solve this issue? :(
> > >
> > >
> > >Greetings
> > > Sebastian
> > >
> > >
> > >[1]
> >
> http://docs.openstack.org/trunk/openstack-network/admin/content/under_the_hood_openvswitch.html
> > >[2] http://pastebin.com/WXMH6y4A
> > >
> > >
> > >--
> > >Sebastian Porombka, M.Sc.
> > >Zentrum f?r Informations- und Medientechnologien (IMT)
> > >Universit?t Paderborn
> > >
> > >
> > >E-Mail: porombka at uni-paderborn.de
> > >Tel.: 05251/60-5999
> > >Fax: 05251/60-48-5999
> > >Raum: N5.314
> > >
> > >
> > >--------------------------------------------
> > >Q: Why is this email five sentences or less?
> > >A: http://five.sentenc.es
> > >
> > >
> > >Please consider the environment before printing this email.
> > >_______________________________________________
> > >OpenStack-operators mailing list
> > >OpenStack-operators at lists.openstack.org
> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > >
> > >
> > >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-operators/attachments/20130902/60036073/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Mon, 2 Sep 2013 17:09:18 +0200
> From: Simon Pasquier <simon.pasquier at bull.net>
> To: <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Running DHCP agent in HA (grizzly)
> Message-ID: <5224AA1E.60201 at bull.net>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> Hello,
> I guess you are running Grizzly. It requires Havana to be able to
> schedule automatically multiple DHCP agents per network.
> Simon
>
> Le 02/09/2013 16:41, Robert van Leeuwen a ?crit :
> > Hi,
> >
> > How would one make sure multiple dhcp agents run for the same segment?
> > I currently have 2 dhcp agents running but only one is added to a
> network when the network is created.
> >
> > When I manually add the other one with "quantum dhcp-agent-network-add"
> but I would like this to happen automatically.
> >
> > Thx,
> > Robert
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
> --
> Simon Pasquier
> Software Engineer
> Bull, Architect of an Open World
> Phone: + 33 4 76 29 71 49
> http://www.bull.com
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 2 Sep 2013 16:28:37 +0100 (BST)
> From: Darragh O'Reilly <dara2002-openstack at yahoo.com>
> To: Lorin Hochstein <lorin at nimbisservices.com>
> Cc: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Quantum Security Groups not working
> - iptables rules are not Evaluated
> Message-ID:
> <1378135717.92851.YahooMailNeo at web172406.mail.ir2.yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Lorin,
>
> sure, sorry for the beverity. It seems the brcompat is being used because
> qbr0188455b-25 appears in the 'ovs-vsctl show' output - so it was created
> as an OVS bridge, but it should have been created as a Linux bridge. I have
> never used brcompat, but I believe it intercepts calls from brctl and
> configures OVS bridges instead of Linux bridges. I'm not sure how to
> uninstall/disable it - it's probably an Operating System package.
>
> I don't think any Openstack doc says to install/enable it.
>
> Re,
> Darragh.
>
> >________________________________
> > From: Lorin Hochstein <lorin at nimbisservices.com>
> >To: Darragh O'Reilly <dara2002-openstack at yahoo.com>
> >Cc: Sebastian Porombka <porombka at uni-paderborn.de>; "
> openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> >Sent: Monday, 2 September 2013, 16:00
> >Subject: Re: [Openstack-operators] Quantum Security Groups not working -
> iptables rules are not Evaluated
> >
> >
> >
> >Darragh:
> >
> >
> >Can you elaborate on this a little more? Do you mean that the "brcompat"
> kernel module has been loaded, and this breaks security groups with the ovs
> plugin? Should we add something in the documentation about this??
> >
> >
> >Lorin
> >
> >
> >
> >
> >Do you mean that the problem is that the ovs-brcompatd service is
> running??
> >
> >
> >openvswitch-brcompat package is installed??
> >
> >
> >
> >On Mon, Sep 2, 2013 at 10:21 AM, Darragh O'Reilly <
> dara2002-openstack at yahoo.com> wrote:
> >
> >
> >>it is not working because you are using the ovs bridge compatibility
> module.
> >>
> >>Re,
> >>Darragh.
> >>
> >>>________________________________
> >>> From: Sebastian Porombka <porombka at uni-paderborn.de>
> >>>To: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> >>>Sent: Monday, 2 September 2013, 14:48
> >>>Subject: [Openstack-operators] Quantum Security Groups not working -
> iptables rules are not Evaluated
> >>
> >>>
> >>>
> >>>
> >>>Hi folks.
> >>>
> >>>
> >>>We're currently on the way to deploy an openstack (grizzly) cloud
> environment?
> >>>and suffering in problems implementing the security groups like
> described in [1].
> >>>
> >>>
> >>>The (hopefully) relevant configuration settings are:
> >>>
> >>>
> >>>/etc/nova/nova.conf
> >>>[?]
> >>>security_group_api=quantum
> >>>network_api_class=nova.network.quantumv2.api.API
> >>>libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
> >>>firewall_driver=nova.virt.firewall.NoopFirewallDriver
> >>>[?]
> >>>
> >>>
> >>>/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
> >>>[?]
> >>>firewall_driver =
> quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> >>>[?]
> >>>
> >>>
> >>>The Networks for the vm's are attached to the compute-nodes via VLAN?
> >>>encapsulation and correctly mapped to the vm's.
> >>>
> >>>
> >>>From our point of view - we're understanding the need of the?
> >>>"ovs-bridge <> veth glue <> linux-bridge (for filtering) <>
> vm"-construction?
> >>>and observed the single components in our deployment. See [2]
> >>>
> >>>
> >>>Everything is working except the security groups.?
> >>>We observed that ip-tables rules are generated for
> the?quantum-openvswi-* chains of iptables.?
> >>>And the traffic arriving untagged (native vlan for management) on the
> machine is processed by iptables but not?
> >>>the traffic which arrived encapsulated.
> >>>
> >>>
> >>>The traffic which is unpacked by openvswitch and is bridged via the
> veth and the tap into?
> >>>the machine isn't processed by the iptables rules.
> >>>
> >>>
> >>>We have no remaining clue/idea how to solve this issue? :(
> >>>
> >>>
> >>>Greetings
> >>>? ?Sebastian
> >>>
> >>>
> >>>[1]?
> http://docs.openstack.org/trunk/openstack-network/admin/content/under_the_hood_openvswitch.html
> >>>[2]?http://pastebin.com/WXMH6y4A
> >>>
> >>>
> >>>--
> >>>Sebastian Porombka,?M.Sc.?
> >>>Zentrum f?r Informations- und Medientechnologien (IMT)
> >>>Universit?t Paderborn
> >>>
> >>>
> >>>E-Mail:?porombka at uni-paderborn.de
> >>>Tel.: 05251/60-5999
> >>>Fax:?05251/60-48-5999
> >>>Raum: N5.314?
> >>>
> >>>
> >>>--------------------------------------------
> >>>Q: Why is this email five sentences or less?
> >>>A:?http://five.sentenc.es
> >>>
> >>>
> >>>Please consider the environment before printing this email.
> >>>_______________________________________________
> >>>OpenStack-operators mailing list
> >>>OpenStack-operators at lists.openstack.org
> >>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>>
> >>>
> >>>
> >>
> >>_______________________________________________
> >>OpenStack-operators mailing list
> >>OpenStack-operators at lists.openstack.org
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >
> >
> >
> >--
> >
> >Lorin Hochstein
> >
> >Lead Architect - Cloud Services
> >Nimbis Services, Inc.
> >www.nimbisservices.com
> >
> >
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 2 Sep 2013 12:51:55 -0300
> From: Juan Jos? Pavlik Salles <jjpavlik at gmail.com>
> To: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Subject: [Openstack-operators] Migrating instances in grizzly
> Message-ID:
> <
> CAKCETkePaRLJz4U96QLhB4_qFgs9R_YUjdVtf4yq8Jbdepoquw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi guys, last friday i started testing live-migration in my grizzly cloud
> with shared storage (gfs2) but i run into a problem, a little weird:
>
> This is the status before migrating:
>
> -I've p9 instances also called instance-00000022 running on "acelga"
> compute node.
>
> *root at acelga:~/tools# virsh list*
> * Id Name State*
> *----------------------------------------------------*
> * 6 instance-00000022 running*
> *
> *
> *root at acelga:~/tools# *
> *
> *
> *
> *
> *root at cebolla:~/tool# virsh list*
> * Id Nombre Estado*
> *----------------------------------------------------*
> *
> *
> *root at cebolla:~/tool# *
>
> -Here you can see all the info about the instance
>
> *root at cebolla:~/tool# nova --os-username=noc-admin --os-tenant-name=noc
> --os-password=XXXXXXX --os-auth-url http://172.19.136.1:35357/v2.0 show
> de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09*
> *
>
> +-------------------------------------+-----------------------------------------------------------+
> *
> *| Property | Value
> |*
> *
>
> +-------------------------------------+-----------------------------------------------------------+
> *
> *| status | ACTIVE
> |*
> *| updated | 2013-09-02T15:27:39Z
> |*
> *| OS-EXT-STS:task_state | None
> |*
> *| OS-EXT-SRV-ATTR:host | acelga
> |*
> *| key_name | None
> |*
> *| image | Ubuntu 12.04.2 LTS
> (1359ca8d-23a2-40e8-940f-d90b3e68bb39) |*
> *| vlan1 network | 172.16.16.175
> |*
> *| hostId |
> 81be94870821e17e327d92e9c80548ffcdd37d24054a235116669f53 |*
> *| OS-EXT-STS:vm_state | active
> |*
> *| OS-EXT-SRV-ATTR:instance_name | instance-00000022
> |*
> *| OS-EXT-SRV-ATTR:hypervisor_hostname | acelga.psi.unc.edu.ar
> |*
> *| flavor | m1.tiny (1)
> |*
> *| id |
> de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09 |*
> *| security_groups | [{u'name': u'default'}]
> |*
> *| user_id | 20390b639d4449c18926dca5e038ec5e
> |*
> *| name | p9
> |*
> *| created | 2013-09-02T15:27:06Z
> |*
> *| tenant_id | d1e3aae242f14c488d2225dcbf1e96d6
> |*
> *| OS-DCF:diskConfig | MANUAL
> |*
> *| metadata | {}
> |*
> *| accessIPv4 |
> |*
> *| accessIPv6 |
> |*
> *| progress | 0
> |*
> *| OS-EXT-STS:power_state | 1
> |*
> *| OS-EXT-AZ:availability_zone | nova
> |*
> *| config_drive |
> |*
> *
>
> +-------------------------------------+-----------------------------------------------------------+
> *
> *root at cebolla:~/tool#*
>
> -So i try to move it to the other node "cebolla"
>
> *root at acelga:~/tools# nova --os-username=noc-admin --os-tenant-name=noc
> --os-password=HjZ5V9yj --os-auth-url
> http://172.19.136.1:35357/v2.0live-migration
> de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09 cebolla
> *
> *root at acelga:~/tools# virsh list*
> * Id Name State*
> *----------------------------------------------------*
> *
> *
> *root at acelga:~/tools#*
>
> No error messages at all on "acelga" compute node so far. If i check the
> other node i can see the instance've been migrated
>
> *root at cebolla:~/tool# virsh list*
> * Id Nombre Estado*
> *----------------------------------------------------*
> * 11 instance-00000022 ejecutando*
> *
> *
> *root at cebolla:~/tool#*
>
>
> -BUT... after a few seconds i get this on "acelga"'s nova-compute.log
>
>
> *2013-09-02 15:35:45.784 4601 DEBUG nova.openstack.common.rpc.common [-]
> Timed out waiting for RPC response: timed out _error_callback
>
> /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py:628
> *
> *2013-09-02 15:35:45.790 4601 ERROR nova.utils [-] in fixed duration
> looping call*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils Traceback (most recent call
> last):*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/utils.py", line 594, in _inner*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils self.f(*self.args, **
> self.kw)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3129,
> in wait_for_live_migration*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils migrate_data)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 3208, in
> _post_live_migration*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils migration)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/conductor/api.py", line 664, in
> network_migrate_instance_start*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils migration)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/conductor/rpcapi.py", line 415, in
> network_migrate_instance_start*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils return
> self.call(context, msg, version='1.41')*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/proxy.py", line
> 80, in call*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils return rpc.call(context,
> self._get_topic(topic), msg, timeout)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/__init__.py",
> line 140, in call*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils return
> _get_impl().call(CONF, context, topic, msg, timeout)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 798, in call*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils
> rpc_amqp.get_connection_pool(conf, Connection))*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 612, in call*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils rv = list(rv)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 554, in __iter__*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils self.done()*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils self.gen.next()*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 551, in __iter__*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils self._iterator.next()*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 648, in iterconsume*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils yield
> self.ensure(_error_callback, _consume)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 566, in ensure*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils error_callback(e)*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 629, in _error_callback*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils raise
> rpc_common.Timeout()*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils Timeout: Timeout while
> waiting on RPC response.*
> *2013-09-02 15:35:45.790 4601 TRACE nova.utils*
>
>
> -And the VM state never changes back to ACTIVE from MIGRATING:
>
>
> *root at cebolla:~/tool# nova --os-username=noc-admin --os-tenant-name=noc
> --os-password=XXXXX --os-auth-url http://172.19.136.1:35357/v2.0 show
> de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09*
> *
>
> +-------------------------------------+-----------------------------------------------------------+
> *
> *| Property | Value
> |*
> *
>
> +-------------------------------------+-----------------------------------------------------------+
> *
> *| status | MIGRATING
> |*
> *| updated | 2013-09-02T15:33:54Z
> |*
> *| OS-EXT-STS:task_state | migrating
> |*
> *| OS-EXT-SRV-ATTR:host | acelga
> |*
> *| key_name | None
> |*
> *| image | Ubuntu 12.04.2 LTS
> (1359ca8d-23a2-40e8-940f-d90b3e68bb39) |*
> *| vlan1 network | 172.16.16.175
> |*
> *| hostId |
> 81be94870821e17e327d92e9c80548ffcdd37d24054a235116669f53 |*
> *| OS-EXT-STS:vm_state | active
> |*
> *| OS-EXT-SRV-ATTR:instance_name | instance-00000022
> |*
> *| OS-EXT-SRV-ATTR:hypervisor_hostname | acelga.psi.unc.edu.ar
> |*
> *| flavor | m1.tiny (1)
> |*
> *| id |
> de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09 |*
> *| security_groups | [{u'name': u'default'}]
> |*
> *| user_id | 20390b639d4449c18926dca5e038ec5e
> |*
> *| name | p9
> |*
> *| created | 2013-09-02T15:27:06Z
> |*
> *| tenant_id | d1e3aae242f14c488d2225dcbf1e96d6
> |*
> *| OS-DCF:diskConfig | MANUAL
> |*
> *| metadata | {}
> |*
> *| accessIPv4 |
> |*
> *| accessIPv6 |
> |*
> *| OS-EXT-STS:power_state | 1
> |*
> *| OS-EXT-AZ:availability_zone | nova
> |*
> *| config_drive |
> |*
> *
>
> +-------------------------------------+-----------------------------------------------------------+
> *
> *root at cebolla:~/tool#*
>
>
> Funny fact:
> -The vm still answer ping after migration, so i think this is good.
>
> Any ideas about this problem? At first i thought it could be related to a
> connection problem between the nodes, but the VM migrates completly in
> hipervisor level somehow there is some "instance've been migrated ACK"
> missing.
>
>
> --
> Pavlik Salles Juan Jos?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-operators/attachments/20130902/e8b7058b/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Mon, 2 Sep 2013 19:12:40 +0000
> From: Sebastian Porombka <porombka at uni-paderborn.de>
> To: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Cc: Holger Nitsche <hn at uni-paderborn.de>
> Subject: Re: [Openstack-operators] Quantum Security Groups not working
> - iptables rules are not Evaluated
> Message-ID: <CE4AAA44.491DD%porombka at uni-paderborn.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi
>
> Yes, openvswitch-brcompat (as ubuntu package) was installed.
> Uninstalling the package removes the qbr* interfaces in
> 'ovs-vsctl show' and solved the problem. Big thanks to you.
>
> Maybe a short sentence in the documentation would be nice. :)
>
> Greetings
> Sebastian
>
> --
> Sebastian Porombka, M.Sc.
> Zentrum f?r Informations- und Medientechnologien (IMT)
> Universit?t Paderborn
>
> E-Mail: porombka at uni-paderborn.de
> Tel.: 05251/60-5999
> Fax: 05251/60-48-5999
> Raum: N5.314
>
> --------------------------------------------
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
> Please consider the environment before printing this email.
>
>
>
>
>
> Am 02.09.13 17:28 schrieb "Darragh O'Reilly" unter
> <dara2002-openstack at yahoo.com>:
>
> >Hi Lorin,
> >
> >sure, sorry for the beverity. It seems the brcompat is being used because
> >qbr0188455b-25 appears in the 'ovs-vsctl show' output - so it was created
> >as an OVS bridge, but it should have been created as a Linux bridge. I
> >have never used brcompat, but I believe it intercepts calls from brctl
> >and configures OVS bridges instead of Linux bridges. I'm not sure how to
> >uninstall/disable it - it's probably an Operating System package.
> >
> >I don't think any Openstack doc says to install/enable it.
> >
> >Re,
> >Darragh.
> >
> >>________________________________
> >> From: Lorin Hochstein <lorin at nimbisservices.com>
> >>To: Darragh O'Reilly <dara2002-openstack at yahoo.com>
> >>Cc: Sebastian Porombka <porombka at uni-paderborn.de>;
> >>"openstack-operators at lists.openstack.org"
> >><openstack-operators at lists.openstack.org>
> >>Sent: Monday, 2 September 2013, 16:00
> >>Subject: Re: [Openstack-operators] Quantum Security Groups not working -
> >>iptables rules are not Evaluated
> >>
> >>
> >>
> >>Darragh:
> >>
> >>
> >>Can you elaborate on this a little more? Do you mean that the "brcompat"
> >>kernel module has been loaded, and this breaks security groups with the
> >>ovs plugin? Should we add something in the documentation about this?
> >>
> >>
> >>Lorin
> >>
> >>
> >>
> >>
> >>Do you mean that the problem is that the ovs-brcompatd service is
> >>running?
> >>
> >>
> >>openvswitch-brcompat package is installed?
> >>
> >>
> >>
> >>On Mon, Sep 2, 2013 at 10:21 AM, Darragh O'Reilly
> >><dara2002-openstack at yahoo.com> wrote:
> >>
> >>
> >>>it is not working because you are using the ovs bridge compatibility
> >>>module.
> >>>
> >>>Re,
> >>>Darragh.
> >>>
> >>>>________________________________
> >>>> From: Sebastian Porombka <porombka at uni-paderborn.de>
> >>>>To: "openstack-operators at lists.openstack.org"
> >>>><openstack-operators at lists.openstack.org>
> >>>>Sent: Monday, 2 September 2013, 14:48
> >>>>Subject: [Openstack-operators] Quantum Security Groups not working -
> >>>>iptables rules are not Evaluated
> >>>
> >>>>
> >>>>
> >>>>
> >>>>Hi folks.
> >>>>
> >>>>
> >>>>We're currently on the way to deploy an openstack (grizzly) cloud
> >>>>environment
> >>>>and suffering in problems implementing the security groups like
> >>>>described in [1].
> >>>>
> >>>>
> >>>>The (hopefully) relevant configuration settings are:
> >>>>
> >>>>
> >>>>/etc/nova/nova.conf
> >>>>[?]
> >>>>security_group_api=quantum
> >>>>network_api_class=nova.network.quantumv2.api.API
> >>>>libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
> >>>>firewall_driver=nova.virt.firewall.NoopFirewallDriver
> >>>>[?]
> >>>>
> >>>>
> >>>>/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
> >>>>[?]
> >>>>firewall_driver =
> >>>>quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> >>>>[?]
> >>>>
> >>>>
> >>>>The Networks for the vm's are attached to the compute-nodes via VLAN
> >>>>encapsulation and correctly mapped to the vm's.
> >>>>
> >>>>
> >>>>From our point of view - we're understanding the need of the
> >>>>"ovs-bridge <> veth glue <> linux-bridge (for filtering) <>
> >>>>vm"-construction
> >>>>and observed the single components in our deployment. See [2]
> >>>>
> >>>>
> >>>>Everything is working except the security groups.
> >>>>We observed that ip-tables rules are generated for the
> >>>>quantum-openvswi-* chains of iptables.
> >>>>And the traffic arriving untagged (native vlan for management) on the
> >>>>machine is processed by iptables but not
> >>>>the traffic which arrived encapsulated.
> >>>>
> >>>>
> >>>>The traffic which is unpacked by openvswitch and is bridged via the
> >>>>veth and the tap into
> >>>>the machine isn't processed by the iptables rules.
> >>>>
> >>>>
> >>>>We have no remaining clue/idea how to solve this issue? :(
> >>>>
> >>>>
> >>>>Greetings
> >>>> Sebastian
> >>>>
> >>>>
> >>>>[1]
> >>>>
> http://docs.openstack.org/trunk/openstack-network/admin/content/under_t
> >>>>he_hood_openvswitch.html
> >>>>[2] http://pastebin.com/WXMH6y4A
> >>>>
> >>>>
> >>>>--
> >>>>Sebastian Porombka, M.Sc.
> >>>>Zentrum f?r Informations- und Medientechnologien (IMT)
> >>>>Universit?t Paderborn
> >>>>
> >>>>
> >>>>E-Mail: porombka at uni-paderborn.de
> >>>>Tel.: 05251/60-5999
> >>>>Fax: 05251/60-48-5999
> >>>>Raum: N5.314
> >>>>
> >>>>
> >>>>--------------------------------------------
> >>>>Q: Why is this email five sentences or less?
> >>>>A: http://five.sentenc.es
> >>>>
> >>>>
> >>>>Please consider the environment before printing this email.
> >>>>_______________________________________________
> >>>>OpenStack-operators mailing list
> >>>>OpenStack-operators at lists.openstack.org
> >>>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>>>
> >>>>
> >>>>
> >>>
> >>>_______________________________________________
> >>>OpenStack-operators mailing list
> >>>OpenStack-operators at lists.openstack.org
> >>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>>
> >>
> >>
> >>
> >>--
> >>
> >>Lorin Hochstein
> >>
> >>Lead Architect - Cloud Services
> >>Nimbis Services, Inc.
> >>www.nimbisservices.com
> >>
> >>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5443 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-operators/attachments/20130902/30940657/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 9
> Date: Mon, 2 Sep 2013 21:44:09 -0300
> From: Juan Jos? Pavlik Salles <jjpavlik at gmail.com>
> To: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Migrating instances in grizzly
> Message-ID:
> <
> CAKCETkfuguB_AAdY9iYfddO65hNF-jVvhiGu62XFu3XhvaoBuQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I've also found this in nova-conductor.log:
>
> 2013-09-02 15:35:27.208 DEBUG nova.openstack.common.rpc.common
> [req-e0473533-89af-4ff5-b6fa-4b0b6eb50a6d 31020076174943bdb7486c330a298d93
> d1e3aae242f14c488d2225dc
> bf1e96d6] Timed out waiting for RPC response: timed out _error_callback
>
> /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py:628
> 2013-09-02 15:35:27.222 ERROR nova.openstack.common.rpc.amqp
> [req-e0473533-89af-4ff5-b6fa-4b0b6eb50a6d 31020076174943bdb7486c330a298d93
> d1e3aae242f14c488d2225dcbf
> 1e96d6] Exception during message handling
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp Traceback
> (most recent call last):
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 430, in _proce
> ss_data
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp rval
> = self.proxy.dispatch(ctxt, version, method, **args)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py",
> line 133, in
> dispatch
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> return getattr(proxyobj, method)(ctxt, **kwargs)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/conductor/manager.py", line 399, in
> network_migrat
> e_instance_start
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> self.network_api.migrate_instance_start(context, instance, migration)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/network/api.py", line 89, in wrapped
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> return func(self, context, *args, **kwargs)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/network/api.py", line 501, in
> migrate_instance_sta
> rt
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> self.network_rpcapi.migrate_instance_start(context, **args)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/network/rpcapi.py", line 333, in
> migrate_instance_
> start
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> version='1.2')
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/proxy.py", line
> 80, in call
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> return rpc.call(context, self._get_topic(topic), msg, timeout)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/__init__.py",
> line 140, in ca
> ll
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> return _get_impl().call(CONF, context, topic, msg, timeout)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 798, in
> call
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> rpc_amqp.get_connection_pool(conf, Connection))
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 612, in call
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp rv =
> list(rv)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 554, in __iter__
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> self.done()
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> self.gen.next()
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 551, in __iter__
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> self._iterator.next()
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 648, in iterconsume
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp yield
> self.ensure(_error_callback, _consume)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 566, in ensure
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> error_callback(e)
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> line 629, in _error_callback
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp raise
> rpc_common.Timeout()
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp Timeout:
> Timeout while waiting on RPC response.
> 2013-09-02 15:35:27.222 1363 TRACE nova.openstack.common.rpc.amqp
> 2013-09-02 15:35:27.237 ERROR nova.openstack.common.rpc.common
> [req-e0473533-89af-4ff5-b6fa-4b0b6eb50a6d 31020076174943bdb7486c330a298d93
> d1e3aae242f14c488d2225dcbf1e96d6] Returning exception Timeout while waiting
> on RPC response. to caller
>
> Does anybody know all the steps that take to live-migrate an instance ?? It
> seems to be stopping inside the network_migrate_instance_start function,
> really no clue at all...
>
>
> 2013/9/2 Juan Jos? Pavlik Salles <jjpavlik at gmail.com>
>
> > Hi guys, last friday i started testing live-migration in my grizzly cloud
> > with shared storage (gfs2) but i run into a problem, a little weird:
> >
> > This is the status before migrating:
> >
> > -I've p9 instances also called instance-00000022 running on "acelga"
> > compute node.
> >
> > *root at acelga:~/tools# virsh list*
> > * Id Name State*
> > *----------------------------------------------------*
> > * 6 instance-00000022 running*
> > *
> > *
> > *root at acelga:~/tools# *
> > *
> > *
> > *
> > *
> > *root at cebolla:~/tool# virsh list*
> > * Id Nombre Estado*
> > *----------------------------------------------------*
> > *
> > *
> > *root at cebolla:~/tool# *
> >
> > -Here you can see all the info about the instance
> >
> > *root at cebolla:~/tool# nova --os-username=noc-admin --os-tenant-name=noc
> > --os-password=XXXXXXX --os-auth-url http://172.19.136.1:35357/v2.0 show
> > de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09*
> > *
> >
> +-------------------------------------+-----------------------------------------------------------+
> > *
> > *| Property | Value
> > |*
> > *
> >
> +-------------------------------------+-----------------------------------------------------------+
> > *
> > *| status | ACTIVE
> > |*
> > *| updated | 2013-09-02T15:27:39Z
> > |*
> > *| OS-EXT-STS:task_state | None
> > |*
> > *| OS-EXT-SRV-ATTR:host | acelga
> > |*
> > *| key_name | None
> > |*
> > *| image | Ubuntu 12.04.2 LTS
> > (1359ca8d-23a2-40e8-940f-d90b3e68bb39) |*
> > *| vlan1 network | 172.16.16.175
> > |*
> > *| hostId |
> > 81be94870821e17e327d92e9c80548ffcdd37d24054a235116669f53 |*
> > *| OS-EXT-STS:vm_state | active
> > |*
> > *| OS-EXT-SRV-ATTR:instance_name | instance-00000022
> > |*
> > *| OS-EXT-SRV-ATTR:hypervisor_hostname | acelga.psi.unc.edu.ar
> > |*
> > *| flavor | m1.tiny (1)
> > |*
> > *| id |
> > de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09 |*
> > *| security_groups | [{u'name': u'default'}]
> > |*
> > *| user_id | 20390b639d4449c18926dca5e038ec5e
> > |*
> > *| name | p9
> > |*
> > *| created | 2013-09-02T15:27:06Z
> > |*
> > *| tenant_id | d1e3aae242f14c488d2225dcbf1e96d6
> > |*
> > *| OS-DCF:diskConfig | MANUAL
> > |*
> > *| metadata | {}
> > |*
> > *| accessIPv4 |
> > |*
> > *| accessIPv6 |
> > |*
> > *| progress | 0
> > |*
> > *| OS-EXT-STS:power_state | 1
> > |*
> > *| OS-EXT-AZ:availability_zone | nova
> > |*
> > *| config_drive |
> > |*
> > *
> >
> +-------------------------------------+-----------------------------------------------------------+
> > *
> > *root at cebolla:~/tool#*
> >
> > -So i try to move it to the other node "cebolla"
> >
> > *root at acelga:~/tools# nova --os-username=noc-admin --os-tenant-name=noc
> > --os-password=HjZ5V9yj --os-auth-url
> http://172.19.136.1:35357/v2.0live-migrationde2bcbed-f7b6-40cd-89ca-acf6fe2f2d09 cebolla
> > *
> > *root at acelga:~/tools# virsh list*
> > * Id Name State*
> > *----------------------------------------------------*
> > *
> > *
> > *root at acelga:~/tools#*
> >
> > No error messages at all on "acelga" compute node so far. If i check the
> > other node i can see the instance've been migrated
> >
> > *root at cebolla:~/tool# virsh list*
> > * Id Nombre Estado*
> > *----------------------------------------------------*
> > * 11 instance-00000022 ejecutando*
> > *
> > *
> > *root at cebolla:~/tool#*
> >
> >
> > -BUT... after a few seconds i get this on "acelga"'s nova-compute.log
> >
> >
> > *2013-09-02 15:35:45.784 4601 DEBUG nova.openstack.common.rpc.common [-]
> > Timed out waiting for RPC response: timed out _error_callback
> >
> /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py:628
> > *
> > *2013-09-02 15:35:45.790 4601 ERROR nova.utils [-] in fixed duration
> > looping call*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils Traceback (most recent
> > call last):*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/utils.py", line 594, in _inner*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils self.f(*self.args, **
> > self.kw)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line
> 3129,
> > in wait_for_live_migration*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils migrate_data)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 3208, in
> > _post_live_migration*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils migration)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/conductor/api.py", line 664, in
> > network_migrate_instance_start*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils migration)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/conductor/rpcapi.py", line 415, in
> > network_migrate_instance_start*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils return
> > self.call(context, msg, version='1.41')*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/proxy.py",
> line
> > 80, in call*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils return
> > rpc.call(context, self._get_topic(topic), msg, timeout)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/__init__.py",
> > line 140, in call*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils return
> > _get_impl().call(CONF, context, topic, msg, timeout)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> >
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> > line 798, in call*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils
> > rpc_amqp.get_connection_pool(conf, Connection))*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py",
> line
> > 612, in call*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils rv = list(rv)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py",
> line
> > 554, in __iter__*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils self.done()*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/contextlib.py", line 24, in __exit__*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils self.gen.next()*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py",
> line
> > 551, in __iter__*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils self._iterator.next()*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> >
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> > line 648, in iterconsume*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils yield
> > self.ensure(_error_callback, _consume)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> >
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> > line 566, in ensure*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils error_callback(e)*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils File
> >
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py",
> > line 629, in _error_callback*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils raise
> > rpc_common.Timeout()*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils Timeout: Timeout while
> > waiting on RPC response.*
> > *2013-09-02 15:35:45.790 4601 TRACE nova.utils*
> >
> >
> > -And the VM state never changes back to ACTIVE from MIGRATING:
> >
> >
> > *root at cebolla:~/tool# nova --os-username=noc-admin --os-tenant-name=noc
> > --os-password=XXXXX --os-auth-url http://172.19.136.1:35357/v2.0 show
> > de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09*
> > *
> >
> +-------------------------------------+-----------------------------------------------------------+
> > *
> > *| Property | Value
> > |*
> > *
> >
> +-------------------------------------+-----------------------------------------------------------+
> > *
> > *| status | MIGRATING
> > |*
> > *| updated | 2013-09-02T15:33:54Z
> > |*
> > *| OS-EXT-STS:task_state | migrating
> > |*
> > *| OS-EXT-SRV-ATTR:host | acelga
> > |*
> > *| key_name | None
> > |*
> > *| image | Ubuntu 12.04.2 LTS
> > (1359ca8d-23a2-40e8-940f-d90b3e68bb39) |*
> > *| vlan1 network | 172.16.16.175
> > |*
> > *| hostId |
> > 81be94870821e17e327d92e9c80548ffcdd37d24054a235116669f53 |*
> > *| OS-EXT-STS:vm_state | active
> > |*
> > *| OS-EXT-SRV-ATTR:instance_name | instance-00000022
> > |*
> > *| OS-EXT-SRV-ATTR:hypervisor_hostname | acelga.psi.unc.edu.ar
> > |*
> > *| flavor | m1.tiny (1)
> > |*
> > *| id |
> > de2bcbed-f7b6-40cd-89ca-acf6fe2f2d09 |*
> > *| security_groups | [{u'name': u'default'}]
> > |*
> > *| user_id | 20390b639d4449c18926dca5e038ec5e
> > |*
> > *| name | p9
> > |*
> > *| created | 2013-09-02T15:27:06Z
> > |*
> > *| tenant_id | d1e3aae242f14c488d2225dcbf1e96d6
> > |*
> > *| OS-DCF:diskConfig | MANUAL
> > |*
> > *| metadata | {}
> > |*
> > *| accessIPv4 |
> > |*
> > *| accessIPv6 |
> > |*
> > *| OS-EXT-STS:power_state | 1
> > |*
> > *| OS-EXT-AZ:availability_zone | nova
> > |*
> > *| config_drive |
> > |*
> > *
> >
> +-------------------------------------+-----------------------------------------------------------+
> > *
> > *root at cebolla:~/tool#*
> >
> >
> > Funny fact:
> > -The vm still answer ping after migration, so i think this is good.
> >
> > Any ideas about this problem? At first i thought it could be related to a
> > connection problem between the nodes, but the VM migrates completly in
> > hipervisor level somehow there is some "instance've been migrated ACK"
> > missing.
> >
> >
> > --
> > Pavlik Salles Juan Jos?
> >
>
>
>
> --
> Pavlik Salles Juan Jos?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-operators/attachments/20130902/d8ca74f2/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> End of OpenStack-operators Digest, Vol 35, Issue 1
> **************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130903/1495e47f/attachment.html>
More information about the OpenStack-operators
mailing list