On Wed, Mar 16, 2022 at 11:30:59AM +0800, Peter Xu wrote: > On Tue, Mar 15, 2022 at 11:15:41AM +0000, Daniel P. Berrangé wrote: > > > I still remember you mentioned the upper layer softwares can have > > > assumption on using only 1 pair of socket for migration, I think that > > > makes > > > postcopy-preempt by default impossible. > > > > > > Why multifd is different here? > > > > It isn't different. We went through the pain to extending libvirt > > to know how to open many channels for multifd. We'll have todo > > the same with this postcopy-pre-empt. To this day though, management > > apps above libvirt largely don't enable multifd, which is a real > > shame. This is the key reason I think we need to handle this at > > the QEMU level automatically. > > But I still don't undertand how QEMU could know about those tunnels, which > should be beyond QEMU's awareness? > > The tunneling program can be some admin initiated socat tcp forwarding > programs, which by default may not allow >1 socket pairs. > > Or maybe I have mis-understood on what's the tunneling we're discussing?
I dont think I was talking about tunneling at all, just QEMU migration protocol options ! If an app is tunnelling QEMU's migration protocol over some channel, that isn't important to QEMU - regardless whether a passed in 'fd:' protocol FD is a direct TCP socket, or a UNIX socket for a tunnel, QEMU works the same way. In one of my other replies I mention a way to make 'fd:' work with an arbitrary number of channels, by using an event from QEMU to request the app provide additional FDs. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|