Re: [Xen-devel] non-dom0 disk backend still not working after recent patches

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-05-01 at 14:27 +0100, Eric Shelton wrote:
> On May 1, 2013, at 4:13 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > On Tue, 2013-04-30 at 18:04 +0100, Eric Shelton wrote:
> >> Will/should xl block-attach make the domU backend disk available to dom0?
> >
> > I think so, it might depend a bit on your dom0 kernel. Although whether
> > you would then be allowed to use it as a guest disk (which I guess is
> > why you are asking) I'm not sure.
> >
> >> Would you expect this to work directly for a PV guest,
> >
> > Yes.
> >
> >> or am I going
> >> to have to turn to pygrub (assuming it similarly facilitates storage
> >> access) or some other mechanism?
> >
> > Actually, pygrub is one thing I would expect not to work (precisely
> > because it needs access to the domain disks in dom0). I'd expect either
> > explicitly providing the kernel or using pvgrub would work.
> >
> > Ian.
> 
> Thanks again.  I got a chance to look into pvgrub a bit more, and I
> see it essentially has the same issue as non-stubdom hvm.

Do you mean pvgrub or pygrub? They are very different beasts.
http://wiki.xen.org/wiki/PvGrub vs http://wiki.xen.org/wiki/PyGrub

> Problems remain in the stubdom code path.  Now it dies in
> xenstore_get_backend_path() in qemu-xen-traditional because bpath
> corresponds to the correct domU path, but the expected path is under
> the dom0 path.  This is because domid_backend is initialized to 0, and
> is never changed.  There is a comment where it is initialized that
> essentially identifies this as a todo.

It's also a bug that this is global since the backend is per device.

> My guess is that the backend domain number should be indicated
> somewhere in the command line for qemu-dm (likely the -disk
> parameters), and then stored in domid-backend.  Does anyone have any
> comments on the appropriate implementation?

For better or worse I think frontends typically parse the backend path
to extract the b.e. domid from it.

> I also will note that this will require a change to
> qemu-xen-traditional.  On the other hand, I expect the change to be
> small, and probably reasonable to roll into 4.3.  However, as
> qemu-cen-traditional appears to be quasi-depricated, I would like to
> know if such a change would be accepted.  A similar change, if not
> already implemented, would also be needed in qemu-xen for
> linux-stubdoms.

I can't say to be honest, as a prerequisite we would normally like to
see the fix posted for qemu-upstream before considering something for
qemu-xen-trad.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel