From: Avi Kivity <avi@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Ryan Harper <ryanh@us.ibm.com>, Amit Shah <amit.shah@redhat.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] To O_EXCL or not to O_EXCL open host_cdrom
Date: Mon, 11 Apr 2011 16:27:54 +0300 [thread overview]
Message-ID: <4DA301DA.7050407@redhat.com> (raw)
In-Reply-To: <BANLkTin3+Hz2kmLnVTDrLyzQUs-Ksvvc0w@mail.gmail.com>
On 04/08/2011 02:33 PM, Stefan Hajnoczi wrote:
> Amit and I were discussing the pros and cons of using O_EXCL to open
> host CD-ROM devices on IRC but this discussion could benefit from more
> input.
>
> Linux block devices (like /dev/sr0 CD-ROMs) can be opened with O_EXCL
> and only one userspace process will succeed at a time. This prevents
> programs from interfering with each other. The polling daemons, hald
> and udisks, use O_EXCL and mount does too.
>
> Today QEMU does not use O_EXCL and will therefore access host CD-ROMs
> while they are in use by other programs. This also means that
> programs can be started on the host while QEMU is already running that
> may interfere with the virtual machine's ability to access the CD-ROM
> (for example by ejecting it).
Also, performance would likely be ruined if the disk wasn't cached
(likely with a DVD). CD-ROMs seek very slowly. It would be even
funnier if we supported cd-writers.
> Therefore, it sounds reasonable to switch to O_EXCL to prevent
> interfering with other programs and to prevent other programs
> interfering with QEMU.
>
> On the downside, it will no longer be possible to share a host CD-ROM
> between multiple virtual machines or to mount it on host while passing
> it through to a guest. These scenarios are not safe because on of the
> clients could eject the device, spoiling the party for everyone else.
> However, it is a handy feature for putting installation media into a
> machine and installing several guests at the same time.
You'd probably benefit a lot more by copying the media to disk.
> The other concern I have about using O_EXCL is that we expose
> ourselves to race conditions if there is ever a need to re-open the
> device. When QEMU closes its file descriptor another program may be
> scheduled to run and open the device with O_EXCL. Now QEMU will not
> be able to open the CD-ROM anymore. From the guest perspective this
> could be at an odd time and we'd have to start failing requests.
> Today we do not re-open host CD-ROMs though so this isn't a pressing
> problem.
We really should avoid re-open whenever possible.
The standard response to such questions is "let's add another option",
but in this case I don't think we should. Like Amit says, this is a
niche use case.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-04-11 13:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 11:33 [Qemu-devel] To O_EXCL or not to O_EXCL open host_cdrom Stefan Hajnoczi
2011-04-11 5:07 ` [Qemu-devel] " Amit Shah
2011-04-11 8:31 ` Stefan Hajnoczi
2011-04-11 13:30 ` Avi Kivity
2011-04-11 13:27 ` Avi Kivity [this message]
2011-04-11 18:19 ` [Qemu-devel] " Christoph Hellwig
2011-04-12 7:52 ` Daniel P. Berrange
2011-04-12 8:10 ` Kevin Wolf
2011-04-12 8:19 ` Daniel P. Berrange
2011-04-12 9:14 ` Stefan Hajnoczi
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=4DA301DA.7050407@redhat.com \
--to=avi@redhat.com \
--cc=amit.shah@redhat.com \
--cc=armbru@redhat.com \
--cc=hch@lst.de \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=ryanh@us.ibm.com \
--cc=stefanha@gmail.com \
/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.