[Qemu-devel] migration: question about buggy implementation of traditional live migration with storage that migrating the storage in iteration way

[Zhanghaoyu (A)]

Hi, all

Could someone make a detailed statement for the buggy implementation of 
traditional live migration with storage that migrating the storage in iteration 
way?

Thanks,
Zhang Haoyu

>>>> 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.
>
>So frankly speaking, there's no real advantage for users now - besides not 
>using buggy implementation.
>
>Michal