[Top][All Lists]

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

Re: [Qemu-devel] PATCH: Control over drive open modes for backing file

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file
Date: Fri, 1 Aug 2008 10:18:09 +0100
User-agent: Mutt/1.4.1i

On Thu, Jul 31, 2008 at 01:26:17PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >The current block driver code will attempt to open a file backing a drive
> >for read/write with O_RDWR first, and if that fails, fallback to opening
> >it readonly with O_RDONLY. So if you set file permissions to readonly on
> >the underlying drive backing store, QEMU will fallback to opening it read
> >only, and discard any writes.
> >  
> I'm not sure I agree that this patch is really that useful to an actual 
> user.  I think we'll eventually need a read-only flag as paravirtual 
> devices do support read-only block devices.  Let's consider a scenario:
> A user has multiple block devices including a secondary device that is 
> read-only to the guest.  With qcow2 and today's behavior, savevm will 
> just work.  With your patch, it will not work.
> This is a scenario where just because the block device cannot be written 
> to, we still would want to write to the metadata of the image.

Sure, the admin of the guest has the option to make it read only or not
depending on whether they need to use this capability.

> So while I think it's valid to have a "read-only disk" exposed to the 
> guest, I don't think the user should have anything to do with how we 
> open the file.
> Is there some specific circumstance you are trying to support?

The scenario is that the admin wants to assign a read only disk to the
virtual machine - typically the same disk to multiple machines - and
thus want to guarentee that no one VM can write to it, since bad things
happen if you do that with non-cluster filesystems.

Controlling this based on the underlying permissions of the file backing
the drive is not practical. Things like udev happy set permissions on
devices in /dev/ behind your back, so you'd have to edit the horrible udev
config files to make /dev/sdXX readonly.  It is a far simpler task to
simply add  ,mode=ro  to the QEMU command line for -drive to accomplish
this, than finding the obscure file to edit to make the underling file
have read only permissions

|: Red Hat, Engineering, London   -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 :|

reply via email to

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