On Mon, 4 Nov 2024 at 22:48, Peter Xu <pet...@redhat.com> wrote: > Firstly, we'll need a way to tell mgmt that the new qemu binary supports > enablement of both multifd + postcopy feature. That can be done with a > > "features": [ "postcopy-with-multifd-precopy" ] > > Flag attached to the QMP "migrate" command.
* IIUC, currently virsh(1)/libvirtd(8) sends the migration command to the destination to inform it of the migration features to use, whether to use multifd or postcopy or none etc. Based on that the destination QEMU prepares to accept incoming VM. Not sure how/what above flag shall benefit. > Then, I think we don't need a magic for preempt channel, because new qemu > binaries (after 7.2) have no issue on out-of-order connections between main > / preempt channel. Preempt channel is always connected later than main. > > It means in the test logic of "which channel is which", it should be: > > - If it's a multifd channel (check multifd header match), it's a multifd > channel, otherwise, > > - if main channel is not present yet, it must be the main channel (and > we can double check the main channel magic), otherwise, > > - it's the preempt channel > > With that, I think we can drop the new magic sent here. * Sending magic value on the postcopy channel only makes it consistent with other channels. There's no harm in sending it. Explicitly defining/sending the magic value is better than leaving it for the code/reader to figure it out. Is there a compelling reason to drop it? IMO, we should either define/send the magic value for all channels or none. Both ways are consistent. Defining it for few and not for others does not seem right. Thank you. --- - Prasad
