All of lore.kernel.org
 help / color / mirror / Atom feed
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: Sun, 04 May 2008 14:19:30 +0300	[thread overview]
Message-ID: <481D9BC2.8030704@qumranet.com> (raw)
In-Reply-To: <481B3191.9020502@codemonkey.ws>

Anthony Liguori wrote:
> Avi Kivity wrote:
>   
>> Well, one user (me) has made this mistake, several times.
>>     
>
> I guess it's usage patterns.  I'm pretty religious about using -snapshot 
> unless I have a very specific reason not to.  I have never encountered 
> this problem myself.
>
>   

Most users cannot use -snapshot for their workloads.

>>> 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.
>>     
>
> Xen tries to be very smart about determining whether devices are mounted 
> somewhere else or not.
>
>   

I'm not talking about being too smart.  Just an flock().

>>> 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)
>>     
>
> The problem I have is that the default policy gets very complicated.  At 
> first thought, I would say it's fine as long as exclusive=off was the 
> default for using -snapshot or using raw images.  However, if you create 
> a VM with a qcow image using -snapshot, and then create another one 
> without using snapshot, you're boned.
>   

Well then, default to exclusive=on.  If you're using -shapshot you can 
add the extra parameter as well.

> What we really need is a global configuration file so that individual 
> users can select these defaults according to what makes sense for them.
>
> In the mean time, I think the policy vs. mechanism strongly suggests 
> that exclusive=off should be the default (not to mention maintaining 
> backwards compatibility).
>
>   

The problem is that this is bad for users.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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: Sun, 04 May 2008 14:19:30 +0300	[thread overview]
Message-ID: <481D9BC2.8030704@qumranet.com> (raw)
In-Reply-To: <481B3191.9020502@codemonkey.ws>

Anthony Liguori wrote:
> Avi Kivity wrote:
>   
>> Well, one user (me) has made this mistake, several times.
>>     
>
> I guess it's usage patterns.  I'm pretty religious about using -snapshot 
> unless I have a very specific reason not to.  I have never encountered 
> this problem myself.
>
>   

Most users cannot use -snapshot for their workloads.

>>> 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.
>>     
>
> Xen tries to be very smart about determining whether devices are mounted 
> somewhere else or not.
>
>   

I'm not talking about being too smart.  Just an flock().

>>> 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)
>>     
>
> The problem I have is that the default policy gets very complicated.  At 
> first thought, I would say it's fine as long as exclusive=off was the 
> default for using -snapshot or using raw images.  However, if you create 
> a VM with a qcow image using -snapshot, and then create another one 
> without using snapshot, you're boned.
>   

Well then, default to exclusive=on.  If you're using -shapshot you can 
add the extra parameter as well.

> What we really need is a global configuration file so that individual 
> users can select these defaults according to what makes sense for them.
>
> In the mean time, I think the policy vs. mechanism strongly suggests 
> that exclusive=off should be the default (not to mention maintaining 
> backwards compatibility).
>
>   

The problem is that this is bad for users.


-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2008-05-04 11:19 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
2008-05-02 15:00       ` [Qemu-devel] Re: [kvm-devel] " 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 [this message]
2008-05-04 11:19           ` 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=481D9BC2.8030704@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.