Re: [libvirt PATCH v3 5/5] qemu: enable asynchronous teardown on s390x hosts by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux