[libvirt] [RFC] Design: Tunnelled NBD block disk migration

Michal Privoznik mprivozn at redhat.com
Mon Jul 27 14:57:03 UTC 2015


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




More information about the libvir-list mailing list