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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 27 Jul 2010, Jeremy Fitzhardinge wrote:
>   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.

I think the checks should be in tap_ctl_create.


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