From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Thomas Huth" <thuth@redhat.com>,
"Laszlo Ersek" <lersek@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
peterx@redhat.com, "Paolo Bonzini" <pbonzini@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Leonardo Bras Soares Passos" <lsoaresp@redhat.com>,
"Avihai Horon" <avihaih@nvidia.com>
Subject: [PATCH v3 0/2] migration: switchover-hold flag
Date: Wed, 5 Jul 2023 11:08:22 -0400 [thread overview]
Message-ID: <20230705150825.305076-1-peterx@redhat.com> (raw)
This v3 patchset is based on master. Since I'm not sure how long this
series will take for review, we could probably apply Dan's previous patch
10 first, then when I repost I can provide a revert patch when needed.
v3:
- Rebase only (v2 is not yet applicable after switchover-ack series merged)
A new flag "switchover-hold" is added to allow src qemu explicitly hold
switchover for precopy migration. Note that this flag will not affect
postcopy switchover because src qemu already has migrate-start-postcopy,
which is a finer grained knob just for that. In general this flag only
affects reaching migration completion phase, when set it'll block it from
happening while keep the migration iteration going.
This can be used in two cases so far in my mind:
(1) One can use this parameter to start pre-heating migration (but not
really migrating, so a migrate-cancel will cancel the preheat). When
the user wants to really migrate, just clear the flag. It'll in most
cases migrate immediately because most pages are already synced.
(2) Can also be used as a clean way to do qtest, in many of the precopy
tests we have requirement to run after 1 iteration without completing
the precopy migration. Before that we have either set bandwidth to
ridiculous low value, or tricks on detecting guest memory change over
some adhoc guest memory position. Now we can simply set this flag
then we know precopy won't complete and will just keep going.
The 1st use case may look a bit like COLO where we can actually keep both
QEMU _mostly_ in sync. I'm not sure whether it can be useful anywhere,
though.
Patch 1 will introduce the new flag.
Patch 2 will leverage the new flag to speed up migration-test. An initial
test is this can make migration-test finish within a little bit less than
1m.
Please have a look, thanks.
Peter Xu (2):
migration: switchover-hold parameter
qtest/migration: Use switchover-hold to speedup
qapi/migration.json | 25 +++++++++++--
migration/migration.h | 17 +++++++++
migration/migration-hmp-cmds.c | 3 ++
migration/migration.c | 68 ++++++++++++++++++++++++++++++++--
migration/options.c | 17 +++++++++
tests/qtest/migration-test.c | 39 ++++++++++++++-----
6 files changed, 153 insertions(+), 16 deletions(-)
--
2.41.0
next reply other threads:[~2023-07-05 15:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-05 15:08 Peter Xu [this message]
2023-07-05 15:08 ` [PATCH v3 1/2] migration: switchover-hold parameter Peter Xu
2023-07-05 15:08 ` [PATCH v3 2/2] qtest/migration: Use switchover-hold to speedup Peter Xu
2023-07-05 15:16 ` [PATCH v3 0/2] migration: switchover-hold flag Peter Xu
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=20230705150825.305076-1-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=avihaih@nvidia.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=lersek@redhat.com \
--cc=lsoaresp@redhat.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--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 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.