WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: xl create should refuse to share block devices RW between domains
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Tue, 27 Jul 2010 17:07:28 +0100
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 27 Jul 2010 09:07:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C4F02F5.9050404@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C4E2A06.9070604@xxxxxxxx> <19534.63648.652292.804989@xxxxxxxxxxxxxxxxxxxxxxxx> <4C4EF9FF.6090906@xxxxxxxx> <19534.64573.809611.586846@xxxxxxxxxxxxxxxxxxxxxxxx> <4C4F02F5.9050404@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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