<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Dear All,<br><br></div>I continue my work on the tunnelled selective block disks migration and the next step is to implement Tunnelled NBD block disk migration.<br><br></div>As far as I see libvirt uses the following algorithm for tunnelling the QEMU migration stream that is unidirectional:<br></div>1. The qemuMigrationStartTunnel (src/qemu/qemu_migration.c) starts a thread that reads the data from the local QEMU pipe and writes it to the virStream using virStreamSend.<br></div>2. The stream used by virStreamSend is embedded in the remote protocol messaging by the remoteDomainMigratePrepareTunnel3{,Params} (src/remote/remote_driver.c).<br></div>3. Remote links the daemonStream with the virFDStream connected  to the write end of a pipe linked with the QEMU.<br></div>4. Overall stream path is then: QEMU -(pipe)> virStreamSend -> (message passing to the remote) -> TCP -> (message received by deamon/*.c code) -> virStreamSend -> virFDStreamWrite -(pipe)> QEMU.<br><br></div>Given that I wonder what should be the changes required to implement a bidirectional QEMU tunnelled connection for the NBD device disk migration.<br><br></div>The way I see implementation details at the moment:<br></div><div>0. The `virStream` and corresponding `daemon/*.c` must be modified in a way that multiple streams can be multiplexed through the only one remote connection.<br></div>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.<br></div>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`.<br></div>3. The receiving code must be modified in such a way to tunnel each of the opened UNIX socket to the according virFDStream.<br><br></div>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.<br><br></div><div>Is my vision on the problem is correct? Are there any other difficulties I'm going to face but not aware of due to the lack of the familiarity with the code?<br><br></div><div>Pavel<br></div></div>