[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.