I don't have anything helpful add but just to mention that whatever
solution is arrived at needs to work with localhost live migrate (which
has historically been broken by any change in this area).
Ian.
On Tue, 2010-07-27 at 16:33 +0100, 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.
>
> > 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 ?
>
> 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).
>
> 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.
>
> Ian.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home