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

[Xen-devel] Re: xl create should refuse to share block devices RW between domains



 On 07/27/2010 08:33 AM, Ian Jackson wrote:
Jeremy Fitzhardinge writes ("Re: xl create should refuse to share block devices RW 
between domains"):
Well, my specific use case is that I have pairs of domain configs, one
PV, one HVM, referring to the same set of resources.  I want xl create
to catch when I try and create the PV version of a domain while the HVM
is still running.
Mmm.  Of course an HVM domain needs to open the underlying device
twice, once for blktap and once for qemu.

Good point. For stubdoms that's pretty obvious if you consider the stubdom to be part of the main domain. For dom0-resident qemu it you need a more subtle check which can match a domain to its corresponding qemu.

A more comprehensive check would be nice, but just this would be
useful.  But whatever it does check should be 100% reliable.
Well, I guess I meant:

  1. Do we have to catch every possible conflict ?  If so then
     your e2fsprogs example is one we need to consider, and we
     will have to add a new kernel feature which can prevent e2fsprogs
     from opening the block device, or simulate "mounting" it or
     something.

  1b. If not, then which conflicts are we trying to detect ?

I think domU vs domU conflicts are the most important, since they can come about from normal operation of the tools. dom0 vs domU requires someone doing something non-tools-related.

  2. If we catch a particular combination (eg, start two domains at
     once using the same storage resources) does our check have to be
     race-free ?  That may make it more complicated - and if the answer
     to my first question is "no" there will be some things which are
     inherently racy (eg, spotting mounting a domain's disk
     vs. starting a domain with a disk which is mounted).

Yes, it needs to be race-free. In general I think that specific invocations of "xl" should be considered atomic operations. For something like domain creation, it should be able to gather and reserve all the resources required before actually starting the domain, and if it can't fail and release everything with a useful message. A test which can fail in certain racy circumstances is useless.

NB that when we fix the bug that you can start multiple domains with
the same name, you'll be able to avoid your PV/HVM accident by
specifying the same name in each config file.

BTW, that's another bug. xl create doesn't prevent two domains with the same name from being created...

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.