Hi, all Could someone make a detailed statement for the buggy implementation of traditional storage-migration method 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 > >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).
