<div dir="ltr">We hit the same issue a while back (I suspect), which we seemed to resolve by pinning QEMU and related packages at the following version (you might need to hunt down the debs manually):<div><br></div><div>1:2.5+dfsg-5ubuntu10.5<br></div><div><br></div><div>I'm certain there's a launchpad bug for Ubuntu qemu regarding this, but don't have it to hand.</div><div><br></div><div>Hope this helps,</div><div>Chris</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 23 Nov 2017 at 15:33 Joe Topjian <<a href="mailto:joe@topjian.net">joe@topjian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>We're seeing some strange libvirt issues in an Ubuntu 16.04 environment. It's running Mitaka, but I don't think this is a problem with OpenStack itself.</div><div><br></div><div>We're in the process of upgrading this environment from Ubuntu 14.04 with the Mitaka cloud archive to 16.04. Instances are being live migrated (NFS share) to a new 16.04 compute node (fresh install), so there's a change between libvirt versions (1.2.2 to 1.3.1). The problem we're seeing is only happening on the 16.04/1.3.1 nodes.</div><div><br></div><div>We're getting occasional reports of instances not able to be snapshotted. Upon investigation, the snapshot process quits early with a libvirt/qemu lock timeout error. We then see that the instance's xml file has disappeared from /etc/libvirt/qemu and must restart libvirt and hard-reboot the instance to get things back to a normal state. Trying to live-migrate the instance to another node causes the same thing to happen.</div><div><br></div><div>However, at some random time, either the snapshot or the migration will work without error. I haven't been able to reproduce this issue on my own and haven't been able to figure out the root cause by inspecting instances reported to me.</div><div><br></div><div>One thing that has stood out is the length of time it takes for libvirt to start. If I run "/etc/init.d/libvirt-bin start", it takes at least 5 minutes before a simple "virsh list" will work. The command will hang otherwise. If I increase libvirt's logging level, I can see that during this period of time, libvirt is working on iptables and ebtables (looks like it's shelling out commands).</div><div><br></div><div>But if I run "libvirtd -l" straight on the command line, all of this completes within 5 seconds (including all of the shelling out).</div><div><br></div><div>My initial thought is that systemd is doing some type of throttling between the system and user slice, but I've tried comparing slice attributes and, probably due to my lack of understanding of systemd, can't find anything to prove this.</div><div><br></div><div>Is anyone else running into this problem? Does anyone know what might be the cause?</div><div><br></div><div>Thanks,</div><div>Joe</div></div>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div>