On Wed, 5 Jul 2023 10:18:37 +0100
Daniel P. Berrangé <berrange(a)redhat.com> wrote:
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 ?
depending on the size of the guest it can go from seconds for small
guests to dozens of minutes for huge guests
I don't have the numbers at hand for 500G
> 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
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.
what would you think about enabling it by default only for guests that
are capable to run in Secure Execution mode?
With regards,
Daniel