qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: [Qemu-devel] Re: [kvm-devel] Feedback and errors
Date: Fri, 02 May 2008 18:00:12 +0300
User-agent: Thunderbird 2.0.0.12 (X11/20080226)

Anthony Liguori wrote:

2/ two instances of kvm can be passed the same -hda. There is no locking whatsoever. This messes up things seriously.


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.

This is not a situation where the user has a reasonable expectation of what will happen that we violate. If the user is unhappy with the results, it's because the user made a mistake.

Well, one user (me) has made this mistake, several times.

FWIW, the whole override thing for Xen has been an endless source of pain. It's very difficult (if not impossible) to accurately determine if someone else is using the disk.

What's wrong with the standard file locking API? Of course it won't stop non-qemu apps from accessing it, but that's unlikely anyway.

Also, it tends to confuse people trying to do something legitimate more often than helping someone doing something stupid.

-drive exclusive=off (or share=yes)


I very frequently run multiple VMs with the same disk. I do it strictly for the purposes of benchmarking. There are ways to share a disk without using a clustered filesystem.

I imagine only raw format disks, and only as non-root filesystems (or with -shapshot, which should automatically set exclusive=off)?


If a higher level management tool wants to enforce a policy (like libvirt), then let it. We should not be enforcing policies within QEMU though.

I agree that qemu is not the place to enforce policies, but covering a hole that users are likely to step into, while allowing its explicit uncovering, is a good thing. We're not enforcing the policy, only hinting.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]