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

[Eric Shelton <knockknock@gmail.com>]

On Apr 30, 2013, at 12:44 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Tue, 2013-04-30 at 16:40 +0100, Eric Shelton wrote:
>> Although some patches were submitted recently to allow a disk backend
>> domain to be
>> specified, it appears there is still some code that presumes dom0 is
>> the backend.  Has
>> this actually been tested for creating an HVM?  I am hoping someone a
>> bit more familiar
>> with the process of creating an HVM can lend a hand.
>>
>> As an example, I have a FreeBSD-based domU (9.1 HVM w/ PV drivers,
>> domid=1, name=freebsd)
>> on which I created a small 40MB test image at /pool1/media/betest.img,
>> to see if I could
>> get another domU to access the image.
>>
>> After applying the patch I sent out a little earlier today and the
>> following xl.cfg line
>> (the below config for hda is my best guess - should this be specified
>> differently?):
>
> It look approximately correct to me.
>
>> disk = [ 'backend=freebsd, format=raw, vdev=hda,
>> target=/pool1/media/betest.img, access=rw',
>>         '/mnt/bootimgs/install-amd64-minimal-20130110.iso,,hdc:cdrom,r' ]
>>
>> I attempt to start up an HVM, but qemu terminates early.  The HVM
>> starts up fine if the
>> hda info is removed.  In the below excerpt from "xl -vvv create ...",
>> it looks like qemu
>> is not informed that hda is on domain 1, not dom0.  I assume the
>> backend domid should be
>> specified on the command line (unless qemu pulls disk info from
>> xenstore, in which case
>> why bother passing any disk parameters via the command line?)
>
> These are the emulated (not PV) disks.
>
> Unfortunately I think we currently have a requirement that the qemu for
> an HVM guest runs in the same domain as the disk backend, since it needs
> to be able to access the disk (or image) directly (qemu doesn't speak
> the PV disk protocol).
>
> In principal we could setup a dom0 vbd for the qemu process to be able
> to access this disk, but currently we do not.
>
> Running with a qemu stubdomain would work around this because the
> stubdomain would speak the PV disk protocol to the driver domain.
>
> Ian.
>

Thank you- I will have to try using a stubdomain.

Two related questions:

Will/should xl block-attach make the domU backend disk available to dom0?

Would you expect this to work directly for a PV guest, or am I going
to have to turn to pygrub (assuming it similarly facilitates storage
access) or some other mechanism?

- Eric