all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Stefan Reiter <s.reiter@proxmox.com>
Subject: [pve-devel] applied: [PATCH qemu-server 2/2] snapshot: set migration caps before savevm-start
Date: Tue, 16 Mar 2021 20:51:29 +0100	[thread overview]
Message-ID: <49f560cb-6b9a-78f9-aa46-7d680ca6e030@proxmox.com> (raw)
In-Reply-To: <20210316163023.24534-2-s.reiter@proxmox.com>

On 16.03.21 17:30, Stefan Reiter wrote:
> A "savevm" call (both our async variant and the upstream sync one) use
> migration code internally. As such, they both expect migration
> capabilities to be set.
> 
> This is usually not a problem, as the default set of capabilities is ok,
> however, it leads to differing snapshot settings if one does a snapshot
> after a machine has been live-migrated (as the capabilities will persist
> from that), which could potentially lead to discrepencies in snapshots
> (currently it seems to be fine, but it still makes sense to set them to
> safeguard against future changes).
> 
> Note that we do set the "dirty-bitmaps" capability now (if
> query-proxmox-support reports true), which has three effects:
> 
> 1) PBS dirty-bitmaps are preserved in snapshots, enabling
>    fast-incremental backups to work after rollback (as long as no newer
>    backups exist), including for hibernate/resume
> 2) snapshots taken from now on, with a QEMU version supporting bitmap
>    migration, *might* lead to incompatibility of these snapshots with
>    QEMU versions that don't know about bitmaps at all (i.e. < 5.0 IIRC?)
>    - forward compatibility is still given, and all other capabilities we
>    set go back to very old versions

not an issue, in practice starting a snapshot made with a newer QEMU with
and older one did not work often due to the running machine version not
being available anyway...

> 3) since we now explicitly disable bitmap saving if the version doesn't
>    report support, we avoid crashes even with not-updated QEMU versions
> 
> Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
> ---
>  PVE/QemuConfig.pm     | 1 +
>  PVE/QemuServer.pm     | 8 ++++++--
>  test/snapshot-test.pm | 2 ++
>  3 files changed, 9 insertions(+), 2 deletions(-)
> 
>

applied, thanks!

Albeit it feels like this could have been two patches and a short comment
for the set_migration_caps calls, as they can be slightly unexpected for
someone not knowing that half the things QEMU can do base on the migrate
code.




  reply	other threads:[~2021-03-16 19:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16 16:30 [pve-devel] [PATCH pve-qemu 1/2] fix saving and loading dirty bitmaps in snapshots Stefan Reiter
2021-03-16 16:30 ` [pve-devel] [PATCH qemu-server 2/2] snapshot: set migration caps before savevm-start Stefan Reiter
2021-03-16 19:51   ` Thomas Lamprecht [this message]
2021-03-16 19:48 ` [pve-devel] applied: [PATCH pve-qemu 1/2] fix saving and loading dirty bitmaps in snapshots Thomas Lamprecht

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=49f560cb-6b9a-78f9-aa46-7d680ca6e030@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.reiter@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 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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal