public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [RFC v2 qemu] savevm-async: reuse migration blocker check for snapshots/hibernation
Date: Wed, 11 Sep 2024 16:09:10 +0200	[thread overview]
Message-ID: <20240911140910.190670-1-f.ebner@proxmox.com> (raw)

Same rationale as with upstream QEMU commit 5aaac46793 ("migration:
savevm: consult migration blockers"), migration and (async) snapshot
are essentially the same operation and thus snapshot also needs to
check for migration blockers. For example, this catches passed-through
PCI devices, where the driver does not support migration.

However, the commit notes:

> There is really no difference between live migration and savevm, except
> that savevm does not require bdrv_invalidate_cache to be implemented
> by all disks.  However, it is unlikely that savevm is used with anything
> except qcow2 disks, so the penalty is small and worth the improvement
> in catching bad usage of savevm.

and for Proxmox VE, suspend-to-disk with VMDK does use savevm-async
and would be broken by simply using migration_is_blocked(). To keep
this working, introduce a new helper that filters blockers with the
prefix used by the VMDK migration blocker.

The function qemu_savevm_state_blocked() is called as part of
savevm_async_is_blocked() so no check is lost with this
patch. The helper is declared in migration/migration.c to be able to
access the 'migration_blockers'.

The VMDK blocker message is declared via a '#define', because using a
'const char*' led to the linker to complain about multiple
declarations. The message does not include the reference to the block
node anymore, but it would've just been a generated one like
'#block334' in any case, which didn't help users identify the VMDK
disk before the change either.

Note, this also "breaks" snapshot and hibernate with VNC clipboard by
preventing it. Previously, this would "work", because the Proxmox VE
API has no check yet, but the clipboard will be broken after rollback,
in the sense that it cannot be used anymore, not just lost contents.
So some users might consider adding the check here a breaking change
even if it's technically correct to prevent snapshot and hibernate
with VNC clipboard. But other users might rightfully complain about
broken clipboard. And again, the check also prevents blockers from
passed-through PCI devices, etc. so it seems worth tolerating that
breakage.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---

Changes in v2:
    * hard-code blocker message to get a conflict if it changes
      upstream.
    * avoid making helper more general than it needs to be (had a
      parameter for matching the prefix of blocker messages).

 block/vmdk.c                |  4 +---
 include/migration/blocker.h |  2 ++
 migration/migration.c       | 24 ++++++++++++++++++++++++
 migration/migration.h       |  1 +
 migration/savevm-async.c    |  2 +-
 5 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/block/vmdk.c b/block/vmdk.c
index 3b82979fdf..eb15109620 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1403,9 +1403,7 @@ static int vmdk_open(BlockDriverState *bs, QDict *options, int flags,
     qemu_co_mutex_init(&s->lock);
 
     /* Disable migration when VMDK images are used */
-    error_setg(&s->migration_blocker, "The vmdk format used by node '%s' "
-               "does not support live migration",
-               bdrv_get_device_or_node_name(bs));
+    error_setg(&s->migration_blocker, "%s", MIGRATION_BLOCKER_VMDK);
     ret = migrate_add_blocker_normal(&s->migration_blocker, errp);
     if (ret < 0) {
         goto fail;
diff --git a/include/migration/blocker.h b/include/migration/blocker.h
index a687ac0efe..f36bfb2df1 100644
--- a/include/migration/blocker.h
+++ b/include/migration/blocker.h
@@ -18,6 +18,8 @@
 
 #define MIG_MODE_ALL MIG_MODE__MAX
 
+#define MIGRATION_BLOCKER_VMDK "The vmdk format used by a disk does not support live migration"
+
 /**
  * @migrate_add_blocker - prevent all modes of migration from proceeding
  *
diff --git a/migration/migration.c b/migration/migration.c
index b8d7e471a4..b18c3720b2 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1913,6 +1913,30 @@ bool migration_is_blocked(Error **errp)
     return false;
 }
 
+bool savevm_async_is_blocked(Error **errp)
+{
+    GSList *blockers = migration_blockers[migrate_mode()];
+
+    if (qemu_savevm_state_blocked(errp)) {
+        return true;
+    }
+
+    /*
+     * The limitation for VMDK images only applies to live-migration, not
+     * snapshots, see commit 5aaac46793 ("migration: savevm: consult migration
+     * blockers").
+     */
+    while (blockers) {
+        if (strcmp(error_get_pretty(blockers->data), MIGRATION_BLOCKER_VMDK)) {
+            error_propagate(errp, error_copy(blockers->data));
+            return true;
+        }
+        blockers = g_slist_next(blockers);
+    }
+
+    return false;
+}
+
 /* Returns true if continue to migrate, or false if error detected */
 static bool migrate_prepare(MigrationState *s, bool blk, bool blk_inc,
                             bool resume, Error **errp)
diff --git a/migration/migration.h b/migration/migration.h
index 8045e39c26..8834050ba8 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -485,6 +485,7 @@ int migration_call_notifiers(MigrationState *s, MigrationEventType type,
 
 int migrate_init(MigrationState *s, Error **errp);
 bool migration_is_blocked(Error **errp);
+bool savevm_async_is_blocked(Error **errp);
 /* True if outgoing migration has entered postcopy phase */
 bool migration_in_postcopy(void);
 bool migration_postcopy_is_alive(int state);
diff --git a/migration/savevm-async.c b/migration/savevm-async.c
index fb4e8ea689..93b1044f77 100644
--- a/migration/savevm-async.c
+++ b/migration/savevm-async.c
@@ -363,7 +363,7 @@ void qmp_savevm_start(const char *statefile, Error **errp)
         return;
     }
 
-    if (qemu_savevm_state_blocked(errp)) {
+    if (savevm_async_is_blocked(errp)) {
         return;
     }
 
-- 
2.39.2



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


                 reply	other threads:[~2024-09-11 14:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20240911140910.190670-1-f.ebner@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal