[libvirt] [PATCHv2] Don't allow two or more disks to be mapped to the same image file

Nathan Baum n at p12a.org.uk
Fri Mar 25 09:18:56 UTC 2011


On Fri, 25 Mar 2011 14:26:16 +0800
Hu Tao <hutao at cn.fujitsu.com> wrote:

> On Thu, Mar 24, 2011 at 11:05:08AM +0000, Nathan Baum wrote:
> > On Thu, 24 Mar 2011 16:46:14 +0800
> > Hu Tao <hutao at cn.fujitsu.com> wrote:
> > 
> > > If two or more disks are mapped to the same image file, operating
> > > on these disks at the same time may corrupt data stored in the
> > > image file.
> > > 
> > > changes:
> > > 
> > > v2:
> > > 
> > > - allow it for read-only disks
> > > - compare source files by inode number
> > >
> > 
> > It doesn't seem that virDomainDiskConflict observes the "shared"
> > property of a disk definition.
> > 
> > If all the disks are marked as shared, we should say there is no
> > conflict.
> 
> Does the "shared" property mean virtual disks can be shared between
> domains or the source of virtual disk can be shared between different
> virtual disks? If it is the former, then the operation of sharing is
> based on virtual disks, thus no need to care about this case.  But if
> it is the latter, we indeed have to check for the "shared" property.
> 

I don't believe libvirt exposes a mechanism for sharing virtual devices
between domains. The only functions I know for adding devices accept
an XML description of the device to add, and I don't believe there is a
way to reference a disk that has been defined on another domain.

Assuming that's true, I don't think the distinction you're asking
about is meaningful. If disks can't be shared, then sharedness must
apply to sources to be at all meaningful. But I'm happy to be proven
wrong. :)

My current workflow is that I create domain XML for each domain, which,
when the storage is shared, contains identical <disk> stanza with
<shareable/> elements. Naturally, I'd like to continue using that
workflow.




More information about the libvir-list mailing list