On Wed, 5 Jul 2023 10:18:37 +0100 Daniel P. Berrangé <berrange@xxxxxxxxxx> 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
