Re: [Qemu-devel] [RFC PATCH 0/2] Fix migration with NFS & iscsi/Fiber channel

[Stefan Hajnoczi]

On Wed, Nov 9, 2011 at 7:16 PM, Juan Quintela <address@hidden> wrote:
> This series goes as RFC, because we need to arrive to a solution for
> qcow2.  In RHEL5/6 we have the equivalent of patch1 integrated to fix
> this issue.

We need to solve this for all block drivers, not just qcow2.

Josh: Have you ever tested live migration with rbd?  Just want to
check if there are any issues to be aware of.  I asked on #ceph and it
seems multiple initiators to a RADOS block device are allowed - this
means Ceph doesn't impose an additional requirement beyond what were
trying to solve for file systems here.

Let me share the situation with QED.  Opening the image file causes
the L1 table to be loaded and reading the first cluster will also
cache an L2 table.  Furthermore, QED has a dirty bit in the file
header to detect unclean shutdown.  The dirty bit will be triggered if
both source and destination machines have the image open for
read-write access simultaneously.  Because of this we either need to
delay opening the image on the destination or we need to open the
image in read-only mode on the destination and then reopen in the
actual mode once the destination has flushed.

I think the delayed open solution is cleanest but probably requires a
final state during live migration where the source says, "I've
transferred everything now, please prepare to take over".  At that
point the destination can open all block devices and if there is an
error can still fail migration.  Unfortunately doing this at the
critical point during live migration means that there is a
latency/timeout situation in case the destination has trouble opening
block devices.  We'd want to abort migration and continue running on
the source but a large timeout means long down-time during failed
migration.

Thoughts?

Stefan