From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
Prasad Pandit <ppandit@redhat.com>,
Juraj Marcin <jmarcin@redhat.com>,
Marco Cavenati <Marco.Cavenati@eurecom.fr>
Subject: Re: [PATCH 1/4] migration/savevm: Add a compatibility check for capabilities
Date: Thu, 27 Mar 2025 14:54:43 +0000 [thread overview]
Message-ID: <Z-Vms2l4jZ_eV-aa@redhat.com> (raw)
In-Reply-To: <20250327143934.7935-2-farosas@suse.de>
On Thu, Mar 27, 2025 at 11:39:31AM -0300, Fabiano Rosas wrote:
> It has always been possible to enable arbitrary migration capabilities
> and attempt to take a snapshot of the VM with the savevm/loadvm
> commands as well as their QMP counterparts
> snapshot-save/snapshot-load.
>
> Most migration capabilities are not meant to be used with snapshots
> and there's a risk of crashing QEMU or producing incorrect
> behavior. Ideally, every migration capability would either be
> implemented for savevm or explicitly rejected.
IMHO, this a prime example of why migration config shouldn't be held
as global state, and instead passed as parameters to the commands
that need them. The snapshot-save/load commands would then only
be able to accept what few settings are actually relevant, instead
of inheriting any/all global migration state.
> Add a compatibility check routine and reject the snapshot command if
> an incompatible capability is enabled. For now only act on the the two
> that actually cause a crash: multifd and mapped-ram.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2818
Issue is 2881 not 2818 ^^^^^^^
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
> migration/options.c | 26 ++++++++++++++++++++++++++
> migration/options.h | 1 +
> migration/savevm.c | 8 ++++++++
> 3 files changed, 35 insertions(+)
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 :|
next prev parent reply other threads:[~2025-03-27 14:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-27 14:39 [PATCH 0/4] migration: savevm testing Fabiano Rosas
2025-03-27 14:39 ` [PATCH 1/4] migration/savevm: Add a compatibility check for capabilities Fabiano Rosas
2025-03-27 14:54 ` Daniel P. Berrangé [this message]
2025-03-27 15:11 ` Fabiano Rosas
2025-04-04 20:26 ` Fabiano Rosas
2025-04-07 12:14 ` Fabiano Rosas
2025-04-11 19:23 ` Fabiano Rosas
2025-03-27 16:46 ` Marco Cavenati
2025-03-27 17:02 ` Fabiano Rosas
2025-03-27 14:39 ` [PATCH 2/4] tests/qtest/migration: Extract machine type resolution Fabiano Rosas
2025-03-27 14:39 ` [PATCH 3/4] tests/qtest/migration: Add QMP helpers for snapshot Fabiano Rosas
2025-03-27 14:39 ` [PATCH 4/4] tests/qtest/migration: Add savevm tests Fabiano Rosas
2025-03-27 14:46 ` [PATCH 0/4] migration: savevm testing Fabiano Rosas
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=Z-Vms2l4jZ_eV-aa@redhat.com \
--to=berrange@redhat.com \
--cc=Marco.Cavenati@eurecom.fr \
--cc=farosas@suse.de \
--cc=jmarcin@redhat.com \
--cc=peterx@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.