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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
