On 17.07.2015 19:10, Pavel Boldin wrote: > 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? Yes it does. Sorry for the late response, I was on a vacation. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list