all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Stefan Reiter <s.reiter@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH 0/4] Keep dirty-bitmaps for PBS during migration
Date: Thu, 22 Oct 2020 17:34:16 +0200	[thread overview]
Message-ID: <20201022153420.16971-1-s.reiter@proxmox.com> (raw)

Allow dirty bitmaps to persist over a live migration, allowing incremental
backups even after a VM has been moved to another node.

Migrating the dirty-bitmaps themselves is supported natively by QEMU, only
requiring a fix for a bug leading to hangs when migrating bitmaps with a
granularity as low as we are using (see first patch).

The second and third patches are the interesting bits, implementing
"savevm"-style migration for all PBS state that is being kept in memory
(checksums).

The last patch brings it all together by enabling it in qemu-server when support
is detected (which is important, since we never want to enable "dirty-bitmaps"
capability on unpatched versions of QEMU, as that will lead to unrecoverable VM
hangs).

Compatility is maintained between all pve-qemu-kvm and qemu-server versions,
with the usual exception of not being able to migrate VMs started with a newer
QEMU version to a machine with an older one.


qemu: Stefan Reiter (2):
  migration/block-dirty-bitmap: fix larger granularity bitmaps
  PVE: Migrate dirty bitmap state via savevm

 include/migration/misc.h       |  3 ++
 migration/Makefile.objs        |  1 +
 migration/block-dirty-bitmap.c |  3 +-
 migration/pbs-state.c          | 92 ++++++++++++++++++++++++++++++++++
 pve-backup.c                   |  1 +
 qapi/block-core.json           |  9 +++-
 softmmu/vl.c                   |  1 +
 7 files changed, 108 insertions(+), 2 deletions(-)
 create mode 100644 migration/pbs-state.c

proxmox-backup-qemu: Stefan Reiter (1):
  add state serializing and loading functions

 Cargo.toml      |  1 +
 current-api.h   | 20 ++++++++++++++++++++
 src/commands.rs | 19 +++++++++++++++++++
 src/lib.rs      | 34 ++++++++++++++++++++++++++++++++++
 4 files changed, 74 insertions(+)

qemu-server: Stefan Reiter (1):
  migrate: enable dirty-bitmap migration

 PVE/QemuServer.pm | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.20.1




             reply	other threads:[~2020-10-22 15:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22 15:34 Stefan Reiter [this message]
2020-10-22 15:34 ` [pve-devel] [PATCH qemu 1/4] migration/block-dirty-bitmap: fix larger granularity bitmaps Stefan Reiter
2020-10-22 15:34 ` [pve-devel] [PATCH qemu 2/4] PVE: Migrate dirty bitmap state via savevm Stefan Reiter
2020-10-22 15:34 ` [pve-devel] [PATCH proxmox-backup-qemu 3/4] add state serializing and loading functions Stefan Reiter
2020-10-28 21:51   ` [pve-devel] applied: " Thomas Lamprecht
2020-10-22 15:34 ` [pve-devel] [PATCH qemu-server 4/4] migrate: enable dirty-bitmap migration Stefan Reiter
2020-10-29 18:13 ` [pve-devel] applied-series: [PATCH 0/4] Keep dirty-bitmaps for PBS during migration 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=20201022153420.16971-1-s.reiter@proxmox.com \
    --to=s.reiter@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 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