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