Re: [Qemu-devel] Re: [kvm-devel] Feedback and errors

[Jamie Lokier]

Daniel P. Berrange wrote:
> > > 2/ two instances of kvm can be passed the same -hda. There is no locking 
> > > whatsoever. This messes up things seriously.
> 
> That depends entirely on what you are doing with the disk in the guest OS.
> 
> The disk could be hosting a cluster filesystem. The guest OS could be
> running on a read-only root FS. The disk could be application raw data
> storage which can be shared (eg Oracle RAC). 

That reminds me, a "read-only" option for disk images would be handy
occasionally.  Writes would return errors, rather than to an expanding
snapshot file.

And then, logically, any default locking for disk images (if you don't
disable it) would use shared locking for a read-only disk image.

> > These two are upstream qemu problems. Copying qemu-devel.
> > 
> > I guess using file locking by default would improve the situation, and 
> > we can add a -drive ...,exclusive=no option for people playing with 
> > cluster filesystems.
> 
> Turning on file locking by default will break existing apps / deployments
> using shared disks. IMHO this is a policy decision that should be solved 
> at ahigher level in the management stack where a whole world view is 
> available rather than QEMU which only knows about its own VM & host.

Imho disk locking should be on by default and easy to turn off.

Casual small scale use of QEMU doesn't use a "management stack", it
uses the command line directly invoking qemu or kvm, or a one-line
script.  In that scenario locking against running two instances _by
mistake_ is most useful (it's easy to accidentally forget you have one
running when hidden on the desktop), and least likely for someone to
use a wrapper.

The few cluster deployments using shared disks will notice very
quickly that an additional option is needed for the new QEMU version.
It won't be the first time a new version has required a change to the
command line options to keep an existing deployment working.

-- Jamie