From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Shelton Subject: Re: non-dom0 disk backend still not working after recent patches Date: Tue, 30 Apr 2013 13:04:54 -0400 Message-ID: <4592741552091255017@unknownmsgid> References: <1367339919.3142.597.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1367339919.3142.597.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" , Eric Shelton List-Id: xen-devel@lists.xenproject.org On Apr 30, 2013, at 12:44 PM, Ian Campbell 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