From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: "Jason Zeng" <jason.zeng@linux.intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Steven Sistare" <steven.sistare@oracle.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH V3 00/22] Live Update [restart]
Date: Thu, 3 Jun 2021 21:44:34 +0100 [thread overview]
Message-ID: <YLk/MoR2Wa20/gU/@redhat.com> (raw)
In-Reply-To: <YLkvShM1MMLh6NpG@work-vm>
On Thu, Jun 03, 2021 at 08:36:42PM +0100, Dr. David Alan Gilbert wrote:
> * Steven Sistare (steven.sistare@oracle.com) wrote:
> > On 5/24/2021 6:39 AM, Dr. David Alan Gilbert wrote:
> > > * Steven Sistare (steven.sistare@oracle.com) wrote:
> > >> On 5/20/2021 9:13 AM, Dr. David Alan Gilbert wrote:
> > >>> On the 'restart' branch of questions; can you explain,
> > >>> other than the passing of the fd's, why the outgoing side of
> > >>> qemu's 'migrate exec:' doesn't work for you?
> > >>
> > >> I'm not sure what I should describe. Can you be more specific?
> > >> Do you mean: can we add the cpr specific bits to the migrate exec code?
> > >
> > > Yes; if possible I'd prefer to just keep the one exec mechanism.
> > > It has an advantage of letting you specify the new command line; that
> > > avoids the problems I'd pointed out with needing to change the command
> > > line if a hotplug had happened. It also means we only need one chunk of
> > > exec code.
> >
> > How/where would you specify a new command line? Are you picturing the usual migration
> > setup where you start a second qemu with its own arguments, plus a migrate_incoming
> > option or command? That does not work for live update restart; the old qemu must exec
> > the new qemu. Or something else?
>
> The existing migration path allows an exec - originally intended to exec
> something like a compressor or a store to file rather than a real
> migration; i.e. you can do:
>
> migrate "exec:gzip > mig"
>
> and that will save the migration stream to a compressed file called mig.
> Now, I *think* we can already do:
>
> migrate "exec:path-to-qemu command line parameters -incoming 'hmmmmm'"
> (That's probably cleaner via the QMP interface).
>
> I'm not quite sure what I want in the incoming there, but that is
> already the source execing the destination qemu - although I think we'd
> probably need to check if that's actually via an intermediary.
I don't think you can dirctly exec qemu in that way, because the
source QEMU migration code is going to wait for completion of the
QEMU you exec'd and that'll never come on success. So you'll end
up with both QEMU's running forever. If you pass the daemonize
option to the new QEMU then it will immediately detach itself,
and the source QEMU will think the migration command has finished
or failed.
I think you can probably do it if you use a wrapper script though.
The wrapper would have to fork QEMU in the backend, and then the
wrapper would have to monitor the new QEMU to see when the incoming
migration has finished/aborted, at which point the wrapper can
exit, so the source QEMU sees a successful cleanup of the exec'd
command. </hand waving>
> > We could shoehorn cpr restart into the migrate exec path by defining a new migration
> > capability that the client would set before issuing the migrate command. However, the
> > implementation code would be sprinkled with conditionals to suppress migrate-only bits
> > and call cpr-only bits. IMO that would be less maintainable than having a separate
> > cprsave function. Currently cprsave does not duplicate any migration functionality.
> > cprsave calls qemu_save_device_state() which is used by xen.
>
> To me it feels like cprsave in particular is replicating more code.
>
> It's also jumping through hoops in places to avoid changing the
> commandline; that's going to cause more pain for a lot of people - not
> just because it's hacks all over for that, but because a lot of people
> are actually going to need to change the commandline even in a cpr like
> case (e.g. due to hotplug or changing something else about the
> environment, like auth data or route to storage or networking that
> changed).
Management apps that already support migration, will almost certainly
know how to start up a new QEMU with a different command line that
takes account of hotplugged/unplugged devices. IOW avoiding changing
the command line only really addresses the simple case, and the hard
case is likely already solved for purposes of handling regular live
migration.
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 :|
next prev parent reply other threads:[~2021-06-03 20:45 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 12:24 [PATCH V3 00/22] Live Update Steve Sistare
2021-05-07 12:24 ` [PATCH V3 01/22] as_flat_walk Steve Sistare
2021-05-07 12:25 ` [PATCH V3 02/22] qemu_ram_volatile Steve Sistare
2021-05-07 12:25 ` [PATCH V3 03/22] oslib: qemu_clr_cloexec Steve Sistare
2021-05-07 12:25 ` [PATCH V3 04/22] util: env var helpers Steve Sistare
2021-05-07 12:25 ` [PATCH V3 05/22] machine: memfd-alloc option Steve Sistare
2021-05-07 12:25 ` [PATCH V3 06/22] vl: add helper to request re-exec Steve Sistare
2021-05-07 14:31 ` Eric Blake
2021-05-13 20:19 ` Steven Sistare
2021-05-14 8:18 ` Daniel P. Berrangé
2021-05-12 16:27 ` Stefan Hajnoczi
2021-05-13 20:20 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 07/22] cpr Steve Sistare
2021-05-12 16:19 ` Stefan Hajnoczi
2021-05-13 20:21 ` Steven Sistare
2021-05-14 11:28 ` Stefan Hajnoczi
2021-05-14 15:14 ` Steven Sistare
2021-05-18 13:42 ` Stefan Hajnoczi
2021-05-07 12:25 ` [PATCH V3 08/22] cpr: QMP interfaces Steve Sistare
2021-06-04 13:59 ` Eric Blake
2021-06-07 17:19 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 09/22] cpr: HMP interfaces Steve Sistare
2021-05-07 12:25 ` [PATCH V3 10/22] pci: export functions for cpr Steve Sistare
2021-05-07 12:25 ` [PATCH V3 11/22] vfio-pci: refactor " Steve Sistare
2021-05-19 22:38 ` Alex Williamson
2021-05-21 13:33 ` Steven Sistare
2021-05-21 21:07 ` Alex Williamson
2021-05-21 21:18 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 12/22] vfio-pci: cpr part 1 Steve Sistare
2021-05-21 22:24 ` Alex Williamson
2021-05-24 18:29 ` Steven Sistare
2021-06-11 18:15 ` Steven Sistare
2021-06-11 19:43 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 13/22] vfio-pci: cpr part 2 Steve Sistare
2021-05-21 22:24 ` Alex Williamson
2021-05-24 18:31 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 14/22] vhost: reset vhost devices upon cprsave Steve Sistare
2021-05-07 12:25 ` [PATCH V3 15/22] hostmem-memfd: cpr support Steve Sistare
2021-05-07 12:25 ` [PATCH V3 16/22] chardev: cpr framework Steve Sistare
2021-05-07 14:33 ` Eric Blake
2021-05-13 20:19 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 17/22] chardev: cpr for simple devices Steve Sistare
2021-05-07 12:25 ` [PATCH V3 18/22] chardev: cpr for pty Steve Sistare
2021-05-07 12:25 ` [PATCH V3 19/22] chardev: cpr for sockets Steve Sistare
2021-05-07 12:25 ` [PATCH V3 20/22] cpr: only-cpr-capable option Steve Sistare
2021-05-07 12:25 ` [PATCH V3 21/22] cpr: maintainers Steve Sistare
2021-05-07 12:25 ` [PATCH V3 22/22] simplify savevm Steve Sistare
2021-05-07 13:00 ` [PATCH V3 00/22] Live Update no-reply
2021-05-13 20:42 ` Steven Sistare
2021-05-12 16:42 ` Stefan Hajnoczi
2021-05-13 20:21 ` Steven Sistare
2021-05-14 11:53 ` Stefan Hajnoczi
2021-05-14 15:15 ` Steven Sistare
2021-05-17 11:40 ` Stefan Hajnoczi
2021-05-17 19:10 ` Alex Williamson
2021-05-18 13:39 ` Stefan Hajnoczi
2021-05-18 15:48 ` Steven Sistare
2021-05-18 9:57 ` Dr. David Alan Gilbert
2021-05-18 16:00 ` Steven Sistare
2021-05-18 19:23 ` Dr. David Alan Gilbert
2021-05-18 20:01 ` Alex Williamson
2021-05-18 20:14 ` Steven Sistare
2021-05-20 13:00 ` [PATCH V3 00/22] Live Update [reboot] Dr. David Alan Gilbert
2021-05-21 14:55 ` Steven Sistare
2021-06-15 19:14 ` Dr. David Alan Gilbert
2021-06-24 15:05 ` Steven Sistare
2021-07-06 17:31 ` Steven Sistare
2021-05-20 13:13 ` [PATCH V3 00/22] Live Update [restart] Dr. David Alan Gilbert
2021-05-21 14:56 ` Steven Sistare
2021-05-24 10:39 ` Dr. David Alan Gilbert
2021-06-02 13:51 ` Steven Sistare
2021-06-03 19:36 ` Dr. David Alan Gilbert
2021-06-03 20:44 ` Daniel P. Berrangé [this message]
2021-06-07 16:40 ` [PATCH V3 00/22] Live Update [restart] : exec Steven Sistare
2021-06-14 14:31 ` Steven Sistare
2021-06-14 14:36 ` Daniel P. Berrangé
2021-06-15 19:05 ` Dr. David Alan Gilbert
2021-06-07 18:08 ` [PATCH V3 00/22] Live Update [restart] : code replication Steven Sistare
2021-06-14 14:33 ` Steven Sistare
2021-05-19 16:43 ` [PATCH V3 00/22] Live Update Steven Sistare
2021-06-02 15:19 ` Steven Sistare
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=YLk/MoR2Wa20/gU/@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jason.zeng@linux.intel.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
--cc=steven.sistare@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.