public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fabian Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [POC qemu-server] fix 3303: allow "live" upgrade of qemu version
Date: Thu,  8 Apr 2021 12:33:10 +0200	[thread overview]
Message-ID: <20210408103316.7619-1-f.ebner@proxmox.com> (raw)

The code is in a very early state, I'm just sending this to discuss the idea.
I didn't do a whole lot of testing yet, but it does seem to work.

The idea is rather simple:
1. save the state to ramfs
2. stop the VM
3. start the VM loading the state

This approach solves the problem that our stack is (currently) not designed to
have multiple instances with the same VM ID running. To do so, we'd need to
handle config locking, sockets, pid file, passthrough resources?, etc.

Another nice feature of this approach is that it doesn't require touching the
vm_start or migration code at all, avoiding further bloating.


Thanks to Fabian G. and Stefan for inspiring this idea:

Fabian G. suggested using the suspend to disk + start route if the required
changes to our stack would turn out to be infeasable.

Stefan suggested migrating to a dummy VM (outside our stack) which just holds
the state and migrating back right away. It seems that dummy VM is in fact not
even needed ;) If we really really care about smallest possible downtime, this
approach might still be the best, and we'd need to start the dummy VM while the
backwards migration runs (resulting in two times the migration downtime). But
it does have more moving parts and requires some migration/startup changes.


Fabian Ebner (6):
  create vmstate_size helper
  create savevm_monitor helper
  draft of upgrade_qemu function
  draft of qemuupgrade API call
  add timing for testing
  add usleep parameter to savevm_monitor

 PVE/API2/Qemu.pm  |  60 ++++++++++++++++++++++
 PVE/QemuConfig.pm |  10 +---
 PVE/QemuServer.pm | 125 +++++++++++++++++++++++++++++++++++++++-------
 3 files changed, 170 insertions(+), 25 deletions(-)

-- 
2.20.1





             reply	other threads:[~2021-04-08 10:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 10:33 Fabian Ebner [this message]
2021-04-08 10:33 ` [pve-devel] [POC qemu-server 1/6] create vmstate_size helper Fabian Ebner
2021-04-08 10:33 ` [pve-devel] [POC qemu-server 2/6] create savevm_monitor helper Fabian Ebner
2021-04-08 10:33 ` [pve-devel] [POC qemu-server 3/6] draft of upgrade_qemu function Fabian Ebner
2021-04-08 10:33 ` [pve-devel] [POC qemu-server 4/6] draft of qemuupgrade API call Fabian Ebner
2021-04-08 10:33 ` [pve-devel] [POC qemu-server 5/6] add timing for testing Fabian Ebner
2021-04-08 10:33 ` [pve-devel] [POC qemu-server 6/6] add usleep parameter to savevm_monitor Fabian Ebner
2021-04-08 16:44 ` [pve-devel] [POC qemu-server] fix 3303: allow "live" upgrade of qemu version Thomas Lamprecht
2021-06-23 17:56   ` Laurent GUERBY

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=20210408103316.7619-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