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 :|
