From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: xl create should refuse to share block devices RW between domains Date: Tue, 27 Jul 2010 08:23:43 -0700 Message-ID: <4C4EF9FF.6090906@goop.org> References: <4C4E2A06.9070604@goop.org> <19534.63648.652292.804989@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <19534.63648.652292.804989@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 07/27/2010 08:17 AM, Ian Jackson wrote: > Jeremy Fitzhardinge writes ("xl create should refuse to share block devices RW between domains"): >> When creating a domain, "xl create" should fail if a block device is >> shared RW between domains, like xm create does. >> >> I'm not sure how this would be implemented. Search xenstore for >> references to the device when setting up a domain? > Does this safety catch have to be 100% reliable ? If not then there > are some useful heuristics: for example, you could see whether the > device is a devmapper device and if so check its open count. That > would catch simultaneously mounting the fs in dom0. 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. A more comprehensive check would be nice, but just this would be useful. But whatever it does check should be 100% reliable. > Doesn't the kernel already have some features to try to stop multiple > conflicting uses of the same block device ? Perhaps blktap[2] should > do the same ? Not in general. The only interlock the kernel has is that you can't change the partition mapping on a device while it is in use. The e2fsprogs do generally try to stop mistakes like fscking a mounted filesystem, but it fails to detect if the block device is being used by blktap (and that does make quite a bit of a mess, it turns out...). J