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

[Juan Quintela <quintela@redhat.com>]

Hi

Some formats (like qcow2) need to "reread" its metadata after
migration (notice that after discussing it with Kevin, it looks like
even raw needs this re-read because it can be resized nowadays).

Notice that this is different of the consistence issues that we used
to have and fixed on NFS with close() + open().  That was discussed
that we only support cache=none for migration, or you have a coherent
clustered filesystem.

The second patch is a big NO-NO.  It only works for some devices, and
Christoph NACKd it.  It is only shown to see what needs to be done.

About the 1st one, now that rely on cache=none or a coherent clustered
filesystem, the operation that we need is "discard all metadata" and
re-read it for disk.  I tried to split qcow2_open() into two functions
(one that opens the file, and other that "reads" the data and failed,
but Kevin told that it shouldn't be difficult).  Kevin?

Related with previous one, it appears that Libvirt would also preffer
to have qemu not-reopen the file, and instead re-read the data,
because for some reason (that I have forgot), they give explicit
permission and then remove it to qemu.  Dan, do you remember?

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.

Comments?

Later, Juan.


[ comment for v1 of the RFC]

This patch set creates infrastructure to invalidate buffers on
migration target machine.  The best way to see the problems is:

# create a new qcow2 image
qemu-img create -f qcow2 foo.img
# start the destination host
qemu .... path=foo.img....
# start the source host with one installation
qemu .... path=foo.img....
# migrate after lots of disk writes

Destination will have "read" the beggining of the blocks of the file
(where the headers are).  There are two bugs here:
a- we need to re-read the image after migration, to have the new values
   (reopening fixes it)
b- we need to be sure that we read the new blocks that are on the server,
   not the buffered ones locally from the start of the run.
   NFS: flush on source and close + open on target invalidates the cache
   Block devices: on linux, BLKFLSBUF invalidates all the buffers for that
   device.  This fixes iSCSI & FiberChannel.

I tested iSCSI & NFS.  NFS patch have been on RHEL5 kvm forever (I just
forget to send the patch upstream).  Our NFS gurus & cluster gurus told
that this is enough for linux to ensure consistence.

Once there, I fixed a couple of minor bugs (the first 3 patches):
- migration should exit with error 1 as everything else.
- memory leak on drive_uninit.
- fix cleanup on error on drive_init()

Juan Quintela (2):
  Reopen files after migration
  drive_open: Add invalidate option for block devices

 block.h           |    2 ++
 block/raw-posix.c |   24 ++++++++++++++++++++++++
 blockdev.c        |   43 ++++++++++++++++++++++++++++++++++++++-----
 blockdev.h        |    6 ++++++
 migration.c       |    6 ++++++
 5 files changed, 76 insertions(+), 5 deletions(-)

-- 
1.7.7