[Openstack-operators] : Public cloud operators group in

I've followed "cloud for at least as long as OpenStack has existed, but back then I followed whatever/whoever called themselves "cloud" or "cloud-{app|service|etc}" and at one point there was a heated discussion (mostly that the rest of the group agreed with) that you couldn't claim you ran in

[Openstack-operators] [ansible] Best practice for single interface cconfig

It's been a while since I deployed OpenStack from scratch so I'm using the Ansible install guide [1] and ran into a problem: How should the hosts be configured for hosts that have one NIC? The test environment layout with one interface [2] is what I'm following but the /etc/network/interface conte

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

Yeah, I saw that in his response. Sounds like a good option if you want to try it. I hadn’t tried it only because I didn’t know about it at the time, and the older version was working fine for us on our other hosts. Mike Smith Lead Cloud Systems Architect Overstock.com

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

Note, in addition to setting mem_stats_period_seconds = 0 in nova.conf, for currently running guests you will also need to manually remove the stats from the vms with something like virsh dommemstat $domname --period 0 --live Thanks, Blake Anderson System Administrator On 9/28/16 11:10 AM, Wi

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

yes thx Corbin, I should try setting mem_stats_period_seconds = 0 in libvirt section of nova.conf and then restart nova-compute on all hosts. Then I can try the live-migration again and see if that prevents VMs from unexpected shutdowns. Hopefully this works, and maybe this goes away with 7.3 when

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

Thank you Mike! I see that setting mem_stats_period_seconds = 0 in nova.conf libvirt section is mentioned in the bug ticket. This has also been mentioned as a workaround by Corbin. Is this something that you have tested? This may be the least intrusive workaround. Thx will On Wed, Sep 28, 2016 at

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

Oh you can read it in the bug thread, but I forgot to mention, if you put in your nova.conf under the libvirt section mem_stats_period_seconds = 0, and restart nova on the destination (although i'd say just do it on both) it will no longer hit the bug. I tested this a couple weeks back with success

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

It unfortunately is affecting virtually all of Redhat's latest qemu-kvm packages. The bug that was unintentionally introduced was done so in response to CVE-2016-5403 Qemu: virtio: unbounded memory allocation on host via guest leading to DoS. Late in the bug thread, they finally posted to a new b

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

William - That is probably what you have hit then. There are several bug tickets out there that are related, I don’t have the specific one I found handy but it’s similar to the one Marcus just posted. I found it by Googling around for the error late one night. In our case, we had most of our

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

> There is a bug in the following: > > qemu-kvm-1.5.3-105.el7_2.7 > qemu-img-1.5.3-105.el7_2.7 > qemu-kvm-common-1.5.3-105.el7_2.7 You might be better of using the RHEV qemu packages They are more recent (2.3) and have more features compiled into them. Cheers, Robert van Leeuwen _

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

thanks Mike! yes, I checked and I've got the versions you mentioned installed: yum list installed | grep "qemu-" qemu-img.x86_64 10:1.5.3-105.el7_2.7 @updates qemu-kvm.x86_64 10:1.5.3-105.el7_2.7 @updates qemu-kvm-common.x86_64 10:1.5.3-105.el7_2.7

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

What's your qemu version, and what does the libvirt log on the destination say? You may have hit this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1371943 There are some workarounds listed there, and downgrading also fixes it. Marcus. On 29 Sep 2016 00:35, "William Josefsson" wrote: > Hi

Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

There is a bug in the following: qemu-kvm-1.5.3-105.el7_2.7 qemu-img-1.5.3-105.el7_2.7 qemu-kvm-common-1.5.3-105.el7_2.7 Are you running these versions? We encountered this same issue and fixed it by running "yum downgrade qemu-kvm qemu-kvm-common qemu-img” which took us back to the el7_2.4

Re: [Openstack-operators] L3 HA Router

Thank you, this was very helpful From: Tobias Urdin Date: Wednesday 28 September 2016 at 12:43 To: David Orn Johannsson Cc: "openstack-operators@lists.openstack.org" Subject: Re: [Openstack-operators] L3 HA Router Hello, Please note that this is no

[Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs

Hi, I have problems with nova live-migration for my CentOS7 and RHEL7 VMs. The live migrations works fine for Windows2012R2 and Ubuntu1404 VMs. For CentOS7/RHEL based images I get this error in the Destination node in nova-compute.log. Also console for logged in VM users on the VM freeze. 2016

Re: [Openstack-operators] L3 HA Router

Hello, Please note that this is not recommended but it's currently the least invasive way (i.e not killing the machine or the keepalived process). * Get the UUID of the L3 router. * Go to the node that hosts your L3 routers (running the neutron-l3-agent service) and show all interfaces in that n

Re: [Openstack-operators] L3 HA Router

I figured this might be the case, but can you tell how I can locate the interface for the router namespace, if I do a ifconfig –a on the network node, I only see the br-* interfaces and the physical ones. I assume, I’d need to take down one of the interfaces that keepalived is responsible for,

Re: [Openstack-operators] L3 HA Router

Hello, Some work was done in that area however it was never completed. https://bugs.launchpad.net/neutron/+bug/1370033 You can issue an ugly failover by taking down the "ha" interface in the router namespace of the master with ifconfig down. But it's not pretty. Best regards On 09/28/2016 11:4

[Openstack-operators] L3 HA Router

OS: Ubuntu 14.04 OpenStack Liberty Is it possible to perform a manual failover of HA routers between master and backup by any sensible means ? ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bi