all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v5 qemu-server 0/3] remote-migration: migration with different cpu
Date: Fri, 17 Nov 2023 08:52:09 +0000	[thread overview]
Message-ID: <33651ae2c41f1ad7c5d61f7c0854f066b6f3c3ab.camel@groupe-cyllene.com> (raw)
In-Reply-To: <20231026085710.1611413-1-aderumier@odiso.com>

Hi,

Any chance to have it one merged for 8.1 ?


-------- Message initial --------
De: Alexandre Derumier <aderumier@odiso.com>
Répondre à: Proxmox VE development discussion <pve-
devel@lists.proxmox.com>
À: pve-devel@lists.proxmox.com
Objet: [pve-devel] [PATCH v5 qemu-server 0/3] remote-migration:
migration with different cpu
Date: 26/10/2023 10:57:07

This patch series allow remote migration between cluster with different
cpu model.

2 new params are introduced: "target-cpu" && "restart"

If target-cpu is defined, this will replace the cpu model of the target
vm.

If vm is online/running, an extra "target-reboot" safeguard option is
needed.
Indeed, as the target cpu is different, the live migration with memory
transfert
is skipped (as anyway, the target will die with a different cpu).

Then, after the storage copy, we switch source vm disk to the targetvm
nbd export,
then shutdown the source vm and restart the target vm.
(Like a virtual reboot between source/target)



We have redone a lot of migration this summer( maybe another 4000vm),
0 corruption, windows or linux guest vms.


Changelog v2:

The first version was simply shuting down the target vm,
wihout doing the block-job-complete.

After doing production migration with around 400vms, I had
some fs corruption, like some datas was still in buffer.

This v2 has been tested with another 400vms batch, without
any corruption.


Changelog v3:

v2 was not perfect, still have some 1 or 2 fs corruption with vms doing
a lot of write.

This v3 retake idea of the v1 but in a cleaner way

- we migrate disk to target vm
- source vm is switching disk to the nbd of the target vm.
  (with a block-job-complete, and not a block-job-cancel with standard
disk migration).
  We are 100% sure it that no pending write is still pending in the
migration job.
- source vm is shutdown
- target with is restart


Changelog v4:
 - bugfix: no not override cpu with empty config if targetcpu is not
defined
 - small cleanups with params

Changelov V5:
 - Fix fiona comments
 - use "restart" param instead "target-reboot"
 - split target-cpu param in separated patch



Alexandre Derumier (3):
  migration: move livemigration code in a dedicated sub
  remote-migration: add restart param
  add target-cpu param

 PVE/API2/Qemu.pm   |  26 +++
 PVE/CLI/qm.pm      |  12 ++
 PVE/QemuMigrate.pm | 452 ++++++++++++++++++++++++---------------------
 3 files changed, 281 insertions(+), 209 deletions(-)



  parent reply	other threads:[~2023-11-17  8:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26  8:57 Alexandre Derumier
2023-10-26  8:57 ` [pve-devel] [PATCH v5 qemu-server 1/3] migration: move livemigration code in a dedicated sub Alexandre Derumier
2023-10-26  8:57 ` [pve-devel] [PATCH v5 qemu-server 2/3] remote-migration: add restart param Alexandre Derumier
2023-10-26  8:57 ` [pve-devel] [PATCH v5 qemu-server 3/3] add target-cpu param Alexandre Derumier
2023-11-17  8:52 ` DERUMIER, Alexandre [this message]
2023-11-17  9:04   ` [pve-devel] [PATCH v5 qemu-server 0/3] remote-migration: migration with different cpu Thomas Lamprecht
2023-11-17  9:11     ` DERUMIER, Alexandre

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=33651ae2c41f1ad7c5d61f7c0854f066b6f3c3ab.camel@groupe-cyllene.com \
    --to=alexandre.derumier@groupe-cyllene.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