[pve-devel] [PATCH v4 qemu-server 2/2] remote-migration: add target-cpu && target-reboot params
Fiona Ebner
f.ebner at proxmox.com
Tue Oct 24 10:11:09 CEST 2023
Am 23.10.23 um 20:03 schrieb DERUMIER, Alexandre:
> 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.
>
That is unfortunate. But thanks for giving it a shot! I guess if we'd
really wanted to go this route, we'd need to add some kind of "empty"
migration type without any state, but would be hard to get right and
feels like a hack.
>
> So I think the best way for now is to restart the target vm.
>
Sure! Going with that is a much cleaner approach then.
More information about the pve-devel
mailing list