Probably a common setup:

Two host servers (A and B) serving multipe guest.
Images stored on common NFS server to both host servers, so migration is possible.

Guests are set-up for auto-start with libvirt.

One host server has to be booted for maintenance. All guests are being manualy migrated to host B.

Host A does boot and auto-start the guests which are now running on host B.

Because the guest disk image files are _not_ locked by kvm, this is successfull and immediately results
in FS corruption on the guests, as two instances of the same guest on different hosts
can access the same filesystem on the common NFS storage.

Solution: please implement flock for guest images accessed by kvm.

severity 631726 wishlist
merge 571063 631726
tags 631726 + confirmed upstream
thanks

26.06.2011 18:56, Benoit Panizzon wrote:
work, both hosts should be able to open the disk images
at the same time - you start kvm on the target host the
same way as you do it on the source host, specifying the
same files.  If source host had them locked, dest. kvm
will not be able to open them.

There's more than migration - there, it should be possible
to release the lock on source, start incoming migration
on target (with locked drives) and handle errors, but that
quickly becomes too ugly.  We also have stacked disk images,
and there, we've similar complexities - the base image should
be locked too when at least one "slave" image _exists_ (not
only open), and there are cases when one need to open it
while it's in use.

There are other valid use cases with even more dangerous
possibilities - for example, quite often I boot my kvm
guest from my main drive - on my physical /dev/sda drive
I've two operating systems installed (win7 and linux), and
sometimes I want to boot win7 while staying in linux -
kvm allows me (after some tweaking of guest side) to boot
natively installed win7 just fine.  Sure thing I wont
be able to boot it this way if qemu will require locking
(or, in this case, exclusive open which is quite something
else).

This has been discussed in qemu mailing list - see several
threads from 2009, say, "Disk image shared and exclusive locks",
"Locking block devices for concurrent access" and a few others.
So far there has been nothing conclusive.

I agree there's a high risk of damaging guest images when
starting multiple qemu/kvm instances off the same image,
and that qemu should try to be more careful by default
(with an option to stop doing these checks/locks), but
the problem is far more deep than you think it is.

For your case there's a trivial workaround: rename the
guest images (place them in a different directory, or
rename the base directory, whatever) before migrating.
This way, you start your incoming migration with new
filenames already, and your source host wont be able
to open them till you actually tell it to do so.

Another possible workaround is to have a flag - eg. a
file in the guest directory - which contains the name
of host which is currently running (or should run) the
guest - and check if that file has current hostname
before starting it.

Or something else of this theme, -- it can become quite
creative.

So, since the problem has a (relatively) easy workaround
(outside of qemu/kvm) and since the underlying problem
is quite deep and involves upstream who hasn't decided
yet what to do with it, I'm marking this bug appropriately -
with severity "wishlist" and appropriate tags.

There's another similar bugreport filed against qemu-kvm
which shows another possible use case - mergeing this bug
with that one while at it, too.

Thanks!

/mjt