From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
"aderumier@odiso.com" <aderumier@odiso.com>,
"f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH v4 qemu-server 2/2] remote-migration: add target-cpu && target-reboot params
Date: Mon, 23 Oct 2023 18:03:18 +0000 [thread overview]
Message-ID: <e572e2c518cc98cc383fb6a554a1324ed1dd2711.camel@groupe-cyllene.com> (raw)
In-Reply-To: <73e0a3a6-f978-ac24-5f6b-16af759ee209@proxmox.com>
Hi Fiona,
>>In case of 'restart' migration, we do want to start the VM anyways,
>>so
>>it's actually better, because we can catch config issues early :) Now
>>that I think about it, can we also just start the target VM in
>>prelaunch
>>mode (instead of incoming migration mode), do the NBD migration, shut
>>down the source VM, stop the NBD server and then resume the target?
>>That
>>would avoid the need to stop and start the target again. And
>>therefore
>>might be quite a bit less downtime.
I have done some tests, It's not possible currently to write to the
remote nbd without the --incoming migration flag and only -S
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05700.html
nbd_add is throwing an error like
2023-10-23 18:45:51 [formationkvm1] VM 111 qmp command 'block-export-
add' failed - Permission conflict on node '#block524': permissions
'write' are both required by an unnamed block device (uses node
'#block524' as 'root' child) and unshared by block device 'drive-scsi0'
(uses node '#block524' as 'root' child).
Looking at the qemu code, the are some specific codepath in block when
the incoming flag is setup.
So I think the best way for now is to restart the target vm.
next prev parent reply other threads:[~2023-10-23 18:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 14:45 [pve-devel] [PATCH v4 qemu-server 0/2] remote-migration: migration with different cpu Alexandre Derumier
2023-09-28 14:45 ` [pve-devel] [PATCH v4 qemu-server 1/2] migration: move livemigration code in a dedicated sub Alexandre Derumier
2023-10-09 11:25 ` Fiona Ebner
2023-09-28 14:45 ` [pve-devel] [PATCH v4 qemu-server 2/2] remote-migration: add target-cpu && target-reboot params Alexandre Derumier
2023-10-09 12:13 ` Fiona Ebner
2023-10-09 13:47 ` DERUMIER, Alexandre
2023-10-10 9:19 ` Fiona Ebner
2023-10-10 16:29 ` DERUMIER, Alexandre
2023-10-11 7:51 ` Fiona Ebner
2023-10-23 18:03 ` DERUMIER, Alexandre [this message]
2023-10-24 8:11 ` Fiona Ebner
2023-10-24 12:20 ` DERUMIER, Alexandre
2023-10-25 8:30 ` Fiona Ebner
2023-10-25 16:01 ` DERUMIER, Alexandre
2023-10-27 9:19 ` Fiona Ebner
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=e572e2c518cc98cc383fb6a554a1324ed1dd2711.camel@groupe-cyllene.com \
--to=alexandre.derumier@groupe-cyllene.com \
--cc=aderumier@odiso.com \
--cc=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 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