Note: I realized the script might want to re-issue the shutdown command but that is for a different time/bug.
After a final test against [1] with the proposed upload being good I pushed this for SRU. Also I added a proper SRU Template to the bug. For SRU Review: libvirt_3.6.0-1ubuntu6.6_source.changes libvirt_1.3.1-1ubuntu10.22_source.changes And the same content, tags and branches for xenial/artful to the packaging repositories. That said waiting for the SRU Team to accept this as next step. [1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3248 ** Description changed: [Impact] - * Due to a bug in a recent fix guests now are immediately considered shut - down. Due to that the helper to shut down guests cleanly might not wait - long enough. + * Due to a bug in a recent fix guests now are immediately considered shut + down. Due to that the helper to shut down guests cleanly might not wait + long enough. - * backporting the upstream fix to the affected releases. + * backporting the upstream fix to the affected releases. [Test Case] - * Spawn a few KVM guests through libvirt, e.g. - $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=bionic label=daily - $ uvt-kvm create --memory 128 --password ubuntu b1 arch=amd64 release=bionic label=daily - $ uvt-kvm create --memory 128 --password ubuntu b2 arch=amd64 release=bionic label=daily - $ uvt-kvm create --memory 128 --password ubuntu b3 arch=amd64 release=bionic label=daily + * Spawn a few KVM guests through libvirt, e.g. + $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=bionic label=daily + $ uvt-kvm create --memory 128 --password ubuntu b1 arch=amd64 release=bionic label=daily + $ uvt-kvm create --memory 128 --password ubuntu b2 arch=amd64 release=bionic label=daily + $ uvt-kvm create --memory 128 --password ubuntu b3 arch=amd64 release=bionic label=daily - * A) Shut down the computer and watch how it handles guest shutdown. + * A) Shut down the computer and watch how it handles guest shutdown. - * B) You can better track that if instead of a shutdown you call what the - shutdown would via: - $ sudo /usr/lib/libvirt/libvirt-guests.sh stop + * B) You can better track that if instead of a shutdown you call what the + shutdown would via: + $ sudo /usr/lib/libvirt/libvirt-guests.sh stop - * It will consider guests as shut down no matter what, so you might want - to modify guests to not shut down or if you have a system to do so use - huge guests with plenty of dirty memory which will slow it down. - + * It will consider guests as shut down no matter what, so you might want + to modify guests to not shut down or if you have a system to do so use + huge guests with plenty of dirty memory which will slow it down. + One good trick is to start the guests right before stopping. + Guests are not yet responding to shutdown signals at that time, so the + issue is revealed (not waiting on shutdown) + To do so you could stop the guests and then do: + $ virsh start b1; virsh start b2; virsh start b3; + $ /usr/lib/libvirt/libvirt-guests.sh stop + The bad case looks like: + Running guests on default URI: b1, b2, b3 + Shutting down guests on default URI... + Starting shutdown on guest: b1 + Starting shutdown on guest: b2 + Starting shutdown on guest: b3 + Waiting for 3 guests to shut down, 120 seconds left + Shutdown of guest b1 complete. + Shutdown of guest b2 complete. + Shutdown of guest b3 complete. + + But you can check with virsh list they are still alive. + The improved case at least properly waits like: + ... + Waiting for 3 guests to shut down, 120 seconds left + Waiting for 3 guests to shut down, 115 seconds left + Waiting for 3 guests to shut down, 110 seconds left + ... + [Regression Potential] - * The fix "only" affects this shutdown handling and no other part of - libvirt which limits the ranges of potential regressions. + * The fix "only" affects this shutdown handling and no other part of + libvirt which limits the ranges of potential regressions. - * The current issue is that we don't wait enough for the geusts, we can't - wait "less" so we won't regress to be less forgiving slow-shutdowns, - but if a mistake would be in the code the regression risk would - be to slow down shutdowns - tests did not see that, but this section is - about regression POTENTIAL so I thought I add it. + * The current issue is that we don't wait enough for the geusts, we can't + wait "less" so we won't regress to be less forgiving slow-shutdowns, + but if a mistake would be in the code the regression risk would + be to slow down shutdowns - tests did not see that, but this section is + about regression POTENTIAL so I thought I add it. [Other Info] - - * n/a + + * n/a --- The recent fix to libvirt-guests.sh.in works for what it intended to fix (variable scope) but failed to adapt the loop in check_guests_shutdown correctly. Due to that it currently detects all guests as "Failed to determine state of guest". It all works, but guests are just assumed dead and logs are spilled with false-positive warnings. A suggested fix is at: https://git.launchpad.net/~paelzer/libvirt/commit/?id=2ccca91678cd1091163490fd0b466b58c8be2b79 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1764668 Title: guest cleanup script fails to iterate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1764668/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
