qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Live Migration with different block devices


From: Xiongzi Ge
Subject: Re: [Qemu-devel] Live Migration with different block devices
Date: Tue, 24 Jun 2014 20:08:38 -0400

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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]