Hi Eric, This really works if I set up the same configuration (/dev/vda in the guest) but the physical block devices are not the same after migration.The ABI is the same. When the guest cache stores a page like 'aaa' which is in the block device of Host A. If the cache in the guest is also migrated to Host B, but data in the block device actually are "bbb" in Host B now. What will happen? Will the cache data in the guest be migrated to the other host? The vmstate function in the qemu seems doing something to save the vm state and the device state.
Should the guest re-open the block device and delete the previous cache data or just check the consistency of the cache and the block device? Thanks. On Tue, Jun 24, 2014 at 7:16 PM, Eric Blake <ebl...@redhat.com> wrote: > On 06/24/2014 03:29 PM, Brian Jackson wrote: > > > > > > On 6/24/2014 2:22 PM, Xiongzi Ge wrote: > >> Hi, > >> > >> > >> When I do live migration, in the source and destination host, there are > >> different block devices, but qemu can not detect this. I used virtio > >> as the > >> driver in kvm and in the vdi device in the guest is /dev/vda. So, > >> the vm > >> guest can read different data from the same /dev/vda device. I am > >> studying > >> this code to let qemu understand that, this is a new device. > >> > >> Does qemu recognize different block devices after live migration? > > > > You aren't supposed to have different command line options when live > > migrating (with the exception of -incoming if you migrate that way). So > > whatever you are trying to do is unsupported. > > Caveat - it IS supported to change command line options for things that > do NOT impact guest ABI. For example, if you have /path/to/file as the > host location containing the guest image on the source, but > /other/path/file as the location on the destination, you CAN rewrite > that parameter (and in fact, libvirt DOES supporting the rewrite such > parameters if you use the 'virsh migrate --xml' option - after first > proving that your changes do not affect guest ABI). But the onus is on > you to ensure that src:/path/to/file and dst:/other/path/file have the > SAME guest-visible contents at the time of the migration (this generally > requires that the two names be mappings to the same underlying network > resource; you can get trickier, but it starts to be at your peril, > because the guest is hosed if the two files differ in guest contents). > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >
