From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, david@redhat.com,
cohuck@redhat.com, thuth@redhat.com, borntraeger@de.ibm.com,
frankja@linux.ibm.com, alex.bennee@linaro.org
Subject: Re: [PATCH v2 1/1] osdep: asynchronous teardown for shutdown on Linux
Date: Fri, 5 Aug 2022 08:59:42 +0200 [thread overview]
Message-ID: <20220805085942.2c5cbce1@p-imbrenda> (raw)
In-Reply-To: <Yuv2nW57bSGdK/1d@redhat.com>
On Thu, 4 Aug 2022 17:41:01 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Thu, Aug 04, 2022 at 04:49:29PM +0200, Claudio Imbrenda wrote:
> > On Thu, 4 Aug 2022 09:29:39 +0100
> > Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > > On Wed, Aug 03, 2022 at 06:34:45PM +0100, Daniel P. Berrangé wrote:
> > > > On Wed, Aug 03, 2022 at 07:31:41PM +0200, Claudio Imbrenda wrote:
> > > > > This patch adds support for asynchronously tearing down a VM on Linux.
> > > > >
> > > > > When qemu terminates, either naturally or because of a fatal signal,
> > > > > the VM is torn down. If the VM is huge, it can take a considerable
> > > > > amount of time for it to be cleaned up. In case of a protected VM, it
> > > > > might take even longer than a non-protected VM (this is the case on
> > > > > s390x, for example).
> > > > >
> > > > > Some users might want to shut down a VM and restart it immediately,
> > > > > without having to wait. This is especially true if management
> > > > > infrastructure like libvirt is used.
> > > > >
> > > > > This patch implements a simple trick on Linux to allow qemu to return
> > > > > immediately, with the teardown of the VM being performed
> > > > > asynchronously.
> > > > >
> > > > > If the new commandline option -async-teardown is used, a new process is
> > > > > spawned from qemu at startup, using the clone syscall, in such way that
> > > > > it will share its address space with qemu.
> > > > >
> > > > > The new process will then simpy wait until qemu terminates, and then it
> > > > > will exit itself.
> > > > >
> > > > > This allows qemu to terminate quickly, without having to wait for the
> > > > > whole address space to be torn down. The teardown process will exit
> > > > > after qemu, so it will be the last user of the address space, and
> > > > > therefore it will take care of the actual teardown.
> > > > >
> > > > > The teardown process will share the same cgroups as qemu, so both
> > > > > memory usage and cpu time will be accounted properly.
> > > > >
> > > > > This feature can already be used with libvirt by adding the following
> > > > > to the XML domain definition:
> > > > >
> > > > > <commandline xmlns="http://libvirt.org/schemas/domain/qemu/1.0">
> > > > > <arg value='-async-teardown'/>
> > > > > </commandline>
> > > >
> > > > How does this work in practice ? Libvirt should be blocking until
> > > > all processes in the cgroup have exited, including this cloned
> > > > child process.
> > >
> > > Also, have you disabled use of seccomp with QEMU when testing this,
> > > as the seccomp filter that libivrt enables is supposed to block
> > > any use of clone() except for the creation of threads.
> >
> > it was just a vanilla libvirt 8.0.0 as found on ubuntu 22.04; I have no
> > idea how it is configured by default
>
> Ok, so the reason it is working is because the extra process is
> cloned() right in middle of processing argv. This is before the
> seccomp filter is applied to the process, so clone() is not blocked.
>
> One think I note about this in practice is that (unsurprisingly)
> if you do a process listing, users now see 2 QEMU processes instead
> of one.
>
> I wonder if we should consider overwriting argv in the child
> process with "[qemu async teardown]" to give users a hint as to
> why this duplicate process exists.
sounds like a good idea
>
> With regards,
> Daniel
next prev parent reply other threads:[~2022-08-05 7:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 17:31 [PATCH v2 1/1] osdep: asynchronous teardown for shutdown on Linux Claudio Imbrenda
2022-08-03 17:34 ` Daniel P. Berrangé
2022-08-04 5:56 ` Claudio Imbrenda
2022-08-04 8:20 ` Daniel P. Berrangé
2022-08-04 16:58 ` Daniel P. Berrangé
2022-08-05 7:02 ` Claudio Imbrenda
2022-08-04 8:29 ` Daniel P. Berrangé
2022-08-04 14:49 ` Claudio Imbrenda
2022-08-04 16:41 ` Daniel P. Berrangé
2022-08-05 6:59 ` Claudio Imbrenda [this message]
2022-08-04 16:56 ` Daniel P. Berrangé
2022-08-05 7:32 ` Claudio Imbrenda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220805085942.2c5cbce1@p-imbrenda \
--to=imbrenda@linux.ibm.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).