Re: non-dom0 disk backend still not working after recent patches

[Eric Shelton <knockknock@gmail.com>]

On May 1, 2013, at 4:13 AM, Ian Campbell <Ian.Campbell@citrix.com> 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.

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.

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?

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.

-Eric