<div dir="ltr">OK, thanks. We'll definitely look at downgrading in a test environment.<div><br></div><div>To add some further info to this problem, here are some log entries. When an instance fails to snapshot or fails to migrate, we see:</div><div><br></div><div><div>libvirtd[27939]: Cannot start job (modify, none) for domain instance-00004fe4; current job is (modify, none) owned by (27942 remoteDispatchDomainBlockJobAbort, 0 <null>) for (69116s, 0s)</div><div><br></div><div>libvirtd[27939]: Cannot start job (none, migration out) for domain instance-00004fe4; current job is (modify, none) owned by (27942 remoteDispatchDomainBlockJobAbort, 0 <null>) for (69361s, 0s)</div></div><div><br></div><div><br></div><div>The one piece of this that I'm currently fixated on is the length of time it takes libvirt to start. I'm not sure if it's causing the above, though. When starting libvirt through systemd, it takes much longer to process the iptables and ebtables rules than if we start libvirtd on the command-line directly.</div><div><br></div><div><div>virFirewallApplyRule:839 : Applying rule '/sbin/ebtables --concurrent -t nat -L libvirt-J-vnet5'</div><div>virFirewallApplyRule:839 : Applying rule '/sbin/ebtables --concurrent -t nat -L libvirt-P-vnet5'</div><div>virFirewallApplyRule:839 : Applying rule '/sbin/ebtables --concurrent -t nat -F libvirt-J-vnet5'</div><div>virFirewallApplyRule:839 : Applying rule '/sbin/ebtables --concurrent -t nat -X libvirt-J-vnet5'</div><div>virFirewallApplyRule:839 : Applying rule '/sbin/ebtables --concurrent -t nat -F libvirt-P-vnet5'</div><div>virFirewallApplyRule:839 : Applying rule '/sbin/ebtables --concurrent -t nat -X libvirt-P-vnet5'</div></div><div><br></div><div>We're talking about a difference between 5 minutes and 5 seconds depending on where libvirt was started. This doesn't seem normal to me. </div><div><br></div><div>In general, is anyone aware of systemd performing restrictions of some kind on processes which create subprocesses? Or something like that? I've tried comparing cgroups and the various limits within systemd between my shell session and the libvirt-bin.service session and can't find anything immediately noticeable. Maybe it's apparmor?</div><div><br></div><div>Thanks,</div><div>Joe</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 11:03 AM, Chris Sarginson <span dir="ltr"><<a href="mailto:csargiso@gmail.com" target="_blank">csargiso@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think we may have pinned libvirt-bin as well, (1.3.1), but I can't guarantee that, sorry - I would suggest its worth trying pinning both initially.<span class="HOEnZb"><font color="#888888"><div><br></div><div>Chris</div></font></span></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, 23 Nov 2017 at 17:42 Joe Topjian <<a href="mailto:joe@topjian.net" target="_blank">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 Chris,<div><br></div><div>Thanks - we will definitely look into this. To confirm: did you also downgrade libvirt as well or was it all qemu? </div><div><br></div><div>Thanks,</div><div>Joe</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 9:16 AM, Chris Sarginson <span dir="ltr"><<a href="mailto:csargiso@gmail.com" target="_blank">csargiso@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div class="m_8173859591112407309m_8411822224674568871h5"><div dir="ltr">On Thu, 23 Nov 2017 at 15:33 Joe Topjian <<a href="mailto:joe@topjian.net" target="_blank">joe@topjian.net</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_8173859591112407309m_8411822224674568871h5"><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></div></div>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</blockquote></div>
</blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>