All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Avi Kivity <avi@qumranet.com>
Cc: nadim khemir <nadim@khemir.net>,
	kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: Re: Feedback and errors
Date: Fri, 2 May 2008 15:45:27 +0100	[thread overview]
Message-ID: <20080502144527.GH5681@redhat.com> (raw)
In-Reply-To: <481AF262.4080305@qumranet.com>

On Fri, May 02, 2008 at 01:52:18PM +0300, Avi Kivity wrote:
> nadim khemir wrote:
> > Hi, great work.
> >
> > While playing with kvm-qemu I noticed a few points that might be of interrest:
> >
> > 1/ -loadvm and -snapshot don't work together. It works as if -loadvm wasn't 
> > passed as argument
> >
> > 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). 

And if the disk is backed by a physical volume which is accessible to
multiple hosts, locking on the VM's host won't provide any safety against
VMs on another host accessing it.

> 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.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

-------------------------------------------------------------------------
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: "Daniel P. Berrange" <berrange@redhat.com>
To: Avi Kivity <avi@qumranet.com>
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, 2 May 2008 15:45:27 +0100	[thread overview]
Message-ID: <20080502144527.GH5681@redhat.com> (raw)
In-Reply-To: <481AF262.4080305@qumranet.com>

On Fri, May 02, 2008 at 01:52:18PM +0300, Avi Kivity wrote:
> nadim khemir wrote:
> > Hi, great work.
> >
> > While playing with kvm-qemu I noticed a few points that might be of interrest:
> >
> > 1/ -loadvm and -snapshot don't work together. It works as if -loadvm wasn't 
> > passed as argument
> >
> > 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). 

And if the disk is backed by a physical volume which is accessible to
multiple hosts, locking on the VM's host won't provide any safety against
VMs on another host accessing it.

> 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.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

  parent reply	other threads:[~2008-05-02 14:45 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
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 [this message]
2008-05-02 14:45     ` 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=20080502144527.GH5681@redhat.com \
    --to=berrange@redhat.com \
    --cc=avi@qumranet.com \
    --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.