[libvirt] why no progress shown after introduce NBD migration cookie

[Zhanghaoyu (A)]

>>>> hi Michal,
>>>>
>>>> I used libvirt-1.0.3, ran below command to perform live migration, why no progress shown up?
>>>> virsh migrate --live --verbose --copy-storage-all <domain>
>>>> qemu+tcp://<dest ip>/system
>>>>
>>>> If replacing libvirt-1.0.3 with libvirt-1.0.2, the migration 
>>>> progress shown up, if performing migration without "--copy-storage-all", the migration progress shown up, too.
>>>>
>>>> Thanks,
>>>> Zhang Haoyu
>>>>
>>>
>>> Because since 1.0.3 we are using NBD to migrate storage. Truth is, 
>>> qemu is reporting progress of storage migration, however, there is no generic formula to combine storage migration and internal state migration into one number. With NBD the process is something like this:
>> 
>> How to use NBD to migrate storage?
>> Does NBD server in destination start automatically as soon as migration initiated, or some other configurations needed?
>> What's the advantages of using NBD to migrate storage over traditional method that migrating the storage in iteration way, just like the way in which migrating the memory?
>> Sorry for my poor knowledge in NBD, by which I used to implement shared storage for live migration without storage.
>
>NBD is used whenever both src and dst of migration is new enough to use it. That is, libvirt >= 1.0.3 and qemu >= 1.0.3. The NBD is turned on by libvirt whenever the conditions are met. User has no control over this.
>The advantage is: only specified disks can be transferred (currently not supported in libvirt), the previous implementation was buggy (according to some qemu developers), the storage is migrated via separate channel (a new connection) so it can be possible (in the future) to split migration of RAM + internal state and storage.

Could you make a detailed statement for the buggy previous implementation, please ?

Thanks,
Zhang Haoyu

>
>So frankly speaking, there's no real advantage for users now - besides not using buggy implementation.
>
>Michal
>
>BTW: It's better to ask these kind of info on the libvir-list next time, others might contribute with much more info as well (e.g. some qemu developers tend to watch the libvir-list too).