[pve-devel] [PATCH v4 qemu-server 2/2] remote-migration: add target-cpu && target-reboot params

[DERUMIER, Alexandre]

>>So I think the best way for now is to restart the target vm.
>>
>>Sure! Going with that is a much cleaner approach then.

I'll try to send a v5 today with you're last comments.

I don't manage yet the unused disks, I need to test with blockdev,

but if it's work, I think we'll need to add config generation in pve-
storage for differents blockdriver


like:

–blockdev driver=file,node-name=file0,filename=vm.img 

–blockdev driver=rbd,node-name=rbd0,pool=my-pool,image=vm01

So maybe it'll take a little bit more time.

(Maybe a second patch serie later to implement it)





-------- Message initial --------
De: Fiona Ebner <f.ebner at proxmox.com>
À: "DERUMIER, Alexandre" <alexandre.derumier at groupe-cyllene.com>, pve-
devel at lists.proxmox.com <pve-devel at lists.proxmox.com>,
aderumier at odiso.com <aderumier at odiso.com>
Objet: Re: [pve-devel] [PATCH v4 qemu-server 2/2] remote-migration: add
target-cpu && target-reboot params
Date: 24/10/2023 10:11:09

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://antiphishing.cetsi.fr/proxy/v3?i=SGI0YVJGNmxZNE90Z2thMFYLWSxJ
> OfIERJocpmb73Vs&r=SW5LV3JodE9QZkRVZ3JEYaKpfBJeBDlAX9E2aicRCRO3qsFIBX9
> zb4pDqGdxG45MOoGKkZ3R8w3DjSjAvqYgRg&f=bnJjU3hQT3pQSmNQZVE3aOdk6YB-
> 6s0kvu35a0_AsxkSltfWi01kMLld3RaPwuBX&u=https%3A//lists.gnu.org/archiv
> e/html/qemu-devel/2017-11/msg05700.html&k=dFBm
> 
> 
> 
> 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.