On Wed, Jul 05, 2023 at 08:20:27AM +0200, Boris Fiuczynski wrote:
Enable by default asynchronous teardown on S390 hosts and add tests for asynchronous teardown autogeneration support. On S390 hosts, Secure Execution guests can take a long time to shutdown, since the memory cleanup can take a long time.
Can you elaborate on this ? What makes it slow, and what kind of magnitude of slowness are we talking abuot. eg for a 500 GB guest, what is the shutdown time for normal vs protected guest ?
Since there is no practical way to determine whether a S390 guest is running in Secure Execution mode, and since the asynchronous teardown does not impact normal (not Secure Execution) guests or guests without large memory configurations, we enable asynchronous teardown by default on S390. A user can select to override the default in the guest domain XML.
It feels pretty sketchy to me to be doing async teardown as a guest arch specific behavioural change. Its been a while since the orignal QEMU discussions, but IIRC, async teardown is not transparent to mgmt apps. Even if the guest has gone from QEMU/libvirt's POV, if the host is still reclaiming memory, the guest RAM is still not available for starting new guests. I fear this is liable to trip up memory accounting logic in mgmt apps, in a hard to understand way because it will be a designed in race condition. I rather think mgmt apps need to explicitly opt-in to async teardown, so they're aware that they need to take account of delayed RAM availablity in their accounting / guest placement logic. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|