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
|
Home