[Qemu-devel] cache=writeback and migrations over shared storage

[Filippos Giannakos]

Hello All,

I stumbled upon this link [1] which among other things contains the following:

"iSCSI, FC, or other forms of direct attached storage are only safe to use with
live migration if you use cache=none."

How valid is this assertion with current QEMU versions?

I checked out the source code and was left with the impression  that
during migration and *before* handling control to the destination, a flush is
performed on all disks of the VM. Since the VM is started on the destination
only after the flush is done, its very first read will bring consistent data
from disk.

I can understand that on the corner case in which the storage device has
already been mapped and perhaps has data in the page cache of the destination
node, there is no way to invalidate them, so the VM will read stale data,
despite the flushes which happened at the source node.

In our case, we provision VMs using our custom storage layer, called
Archipelago [2], which presents volumes as block devices in the host. We would
like to run VMs in cache=writeback mode. If we guarantee externally that there
will be no incoherent cached data on the destination host of the migration
(e.g., by making sure the volume is not mapped on the destination node before
the migration), would it be safe to do so?

Can you comment on the aforementioned approach? Please let me know if there's
something I have misunderstood.

[1] http://wiki.qemu.org/Migration/Storage
[2] http://www.synnefo.org/docs/archipelago/latest

Kind Regards,
-- 
Filippos
<address@hidden>