Re: [libvirt PATCH v3 5/5] qemu: enable asynchronous teardown on s390x hosts by default
On Wed, Jul 05, 2023 at 02:22:37PM +0200, Claudio Imbrenda wrote:
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
Doesn't have to be for 500G - that was just a value i plucked out
of the air. Just interested in any concrete example timings for a
non-trivially small 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
> 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?
IIUC, that's basically /all/ guests if running on new enough hardware
with prot_virt=1 enabled on the host OS, so will still present challenges
to mgmt apps needing to be aware of this behaviour AFAICS.
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 :|