Michal, Please see my comments intermixed below. > > > 1. `Pipe`s used to interconnect to the QEMU on the both sides are obviously > > to be replaced by the UNIX sockets since the pipes cannot support > > bidirectional output due to the design. This is to be made *one for each* > > block device, requiring the above change. > > I'm not sure. Does qemu require bidirectional stream? I guess it should > so that the source is notified about disks switching to mirroring phase. > If that's the case, then you're right. As far as I see the QEMU migration process only uses one-way communication. But I have a feeling that the NBD actually transfers data both ways. > > > > 2. The `qemuMigrationIOFunc` must be rewritten in such a way it polls for > > both read and write on the UNIX sockets *and* VM migration pipe and > > tunnells these to the appropriate `virStream`. > > 3. The receiving code must be modified in such a way to tunnel each of the > > opened UNIX socket to the according virFDStream. > > > > Of the mentioned above the most intriguing for me is the zero-th item which > > will require some changes to the binary remote messaging protocol. > > > Yeah, this is something we really try to avoid. The reason is that older > clients remain compatible with newer servers and vice versa. If we > invent new streams, we should probably invent new RPC calls too; > virBiStream or something like this. This way we can still serve data to > older clients (e.g. screenshots are transferred through virStream and > mangling it will cut off older clients) and use the new feature - in > which case older clients will fail with unknown rpc call. Well, this seems to be the way to do it: implement an RPC call that converts the remoteStream into multiplexing one. This call is to be performed by the migration source when there is the appropriate capability set on the remote's side. Does this looks correct for you? Pavel -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list