From: Avi Kivity <avi@qumranet.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: nadim khemir <nadim@khemir.net>,
kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: Re: Feedback and errors
Date: Fri, 02 May 2008 18:00:12 +0300 [thread overview]
Message-ID: <481B2C7C.8050108@qumranet.com> (raw)
In-Reply-To: <481B2603.3050800@codemonkey.ws>
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.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@qumranet.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: nadim khemir <nadim@khemir.net>,
kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [kvm-devel] Feedback and errors
Date: Fri, 02 May 2008 18:00:12 +0300 [thread overview]
Message-ID: <481B2C7C.8050108@qumranet.com> (raw)
In-Reply-To: <481B2603.3050800@codemonkey.ws>
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.
next prev parent reply other threads:[~2008-05-02 15:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 20:58 Feedback and errors nadim khemir
2008-05-02 10:52 ` Avi Kivity
2008-05-02 10:52 ` [Qemu-devel] Re: [kvm-devel] " Avi Kivity
2008-05-02 14:32 ` Anthony Liguori
2008-05-02 14:32 ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2008-05-02 15:00 ` Avi Kivity [this message]
2008-05-02 15:00 ` Avi Kivity
2008-05-02 15:21 ` Anthony Liguori
2008-05-02 15:21 ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2008-05-04 11:19 ` Avi Kivity
2008-05-04 11:19 ` [Qemu-devel] Re: [kvm-devel] " Avi Kivity
2008-05-04 22:52 ` nadim khemir
2008-05-04 22:52 ` [Qemu-devel] Re: [kvm-devel] " nadim khemir
2008-05-04 12:39 ` Javier Guerra Giraldez
2008-05-04 12:39 ` [Qemu-devel] Re: [kvm-devel] " Javier Guerra Giraldez
2008-05-02 14:45 ` Daniel P. Berrange
2008-05-02 14:45 ` [Qemu-devel] Re: [kvm-devel] " Daniel P. Berrange
2008-05-02 15:02 ` Avi Kivity
2008-05-02 15:02 ` [Qemu-devel] Re: [kvm-devel] " Avi Kivity
2008-05-02 15:23 ` [Qemu-devel] " Jamie Lokier
2008-05-02 15:23 ` [Qemu-devel] Re: [kvm-devel] " Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=481B2C7C.8050108@qumranet.com \
--to=avi@qumranet.com \
--cc=anthony@codemonkey.ws \
--cc=kvm-devel@lists.sourceforge.net \
--cc=nadim@khemir.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.