From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Richard Palethorpe <rpalethorpe@suse.com>
Cc: qemu-devel@nongnu.org, berrange@redhat.com,
qemu-block@nongnu.org, armbru@redhat.com, eblake@redhat.com,
quintela@redhat.com, mreitz@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 1/2] migrate: Allow incoming migration without defer
Date: Thu, 1 Mar 2018 16:59:00 +0000 [thread overview]
Message-ID: <20180301165859.GJ2994@work-vm> (raw)
In-Reply-To: <20180227115651.30762-2-rpalethorpe@suse.com>
* Richard Palethorpe (rpalethorpe@suse.com) wrote:
> Allow a QEMU instance which has been started and used without the "-incoming"
> flag to accept an incoming migration with the "migrate-incoming" QMP
> command. This allows the user to dump the VM state to an external file then
> revert to that state at a later time without restarting QEMU.
> ---
> migration/migration.c | 12 +++++-------
> vl.c | 2 ++
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 0aa596f867..05595a4cec 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1321,14 +1321,14 @@ void migrate_del_blocker(Error *reason)
> void qmp_migrate_incoming(const char *uri, Error **errp)
> {
> Error *local_err = NULL;
> - static bool once = true;
>
> - if (!deferred_incoming) {
> - error_setg(errp, "For use with '-incoming defer'");
> + if (runstate_check(RUN_STATE_INMIGRATE)) {
> + error_setg(errp, "The incoming migration has already been started");
> return;
> }
> - if (!once) {
> - error_setg(errp, "The incoming migration has already been started");
> +
> + if (!deferred_incoming) {
> + vm_stop(RUN_STATE_INMIGRATE);
> }
>
> qemu_start_incoming_migration(uri, &local_err);
> @@ -1337,8 +1337,6 @@ void qmp_migrate_incoming(const char *uri, Error **errp)
> error_propagate(errp, local_err);
> return;
> }
> -
> - once = false;
> }
That's...interesting. I think it will work, but I bet there's a whole
bunch of corner cases [many of which loadvm will hit as well!].
For starters there's probably devices that are active and still looking
at RAM, even though vm_stop is in place (hopefully none of them are
writing to it, but I wouldn't actually trust them). Also, you probably
need to inactivate the block devices?
Also, I think this means there's no protection against this happening
during an outgoing migration (which has an existing check to make sure
you can't start an outgoing migration while an incoming one is waiting).
> bool migration_is_blocked(Error **errp)
> diff --git a/vl.c b/vl.c
> index 9e7235df6d..a91eda039e 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -634,6 +634,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> { RUN_STATE_PAUSED, RUN_STATE_POSTMIGRATE },
> { RUN_STATE_PAUSED, RUN_STATE_PRELAUNCH },
> { RUN_STATE_PAUSED, RUN_STATE_COLO},
> + { RUN_STATE_PAUSED, RUN_STATE_INMIGRATE },
>
> { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
> { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
> @@ -665,6 +666,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> { RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
> { RUN_STATE_RUNNING, RUN_STATE_GUEST_PANICKED },
> { RUN_STATE_RUNNING, RUN_STATE_COLO},
> + { RUN_STATE_RUNNING, RUN_STATE_INMIGRATE },
Experience suggests that you'll find out the hard way that there's other
states you'll need to allow or check for.
For example, do you want to be able to loadvm from a GUEST_PANICKED or
PRELAUNCH state?
Dave
> { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
>
> --
> 2.16.2
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-03-01 16:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 11:56 [Qemu-devel] [RFC PATCH 0/2] Increase usability of external snapshots Richard Palethorpe
2018-02-27 11:56 ` [Qemu-devel] [RFC PATCH 1/2] migrate: Allow incoming migration without defer Richard Palethorpe
2018-03-01 16:59 ` Dr. David Alan Gilbert [this message]
2018-03-05 15:33 ` Richard Palethorpe
2018-02-27 11:56 ` [Qemu-devel] [RFC PATCH 2/2] migrate: Tests for migrating to an already used QEMU Richard Palethorpe
2018-03-01 17:32 ` Dr. David Alan Gilbert
2018-02-27 16:07 ` [Qemu-devel] [RFC PATCH 0/2] Increase usability of external snapshots no-reply
2018-03-02 16:15 ` [Qemu-devel] [Qemu-block] " Roman Kagan
2018-03-05 14:38 ` Richard Palethorpe
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=20180301165859.GJ2994@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rpalethorpe@suse.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).