Re: [Xen-users] SOLVED: storage driver domains

[Kuba <kuba.0000@xxxxx>]

W dniu 2014-08-01 18:53, Roger Pau Monnà pisze:
> Hello,
>
> On 31/07/14 19:10, Kuba wrote:
> > W dniu 2014-07-26 13:42, Kuba pisze:
> > > Thank you for your help, but unfortunately I cannot get it to work (Xen
> > > 4.4 compiled from sources with Debian 7 Dom0 with kernel 3.10.33). I'm
> > > trying to provide storage from one FreeBSD 10 DomU (provider.conf) to
> > > another FreeBSD 10 DomU (consumer.conf). I boot provider DomU in livecd
> > > mode and create a zvol (tank/test). Long story short, I can get consumer
> > > DomU's kernel to see the storage (when booted in livecd mode), but
> > > cannot get the bios to see it too (and boot from it).
> > >
> > > When I try to boot consumer DomU with this in consumer.conf:
> > >
> > > #device_model_version="qemu-xen-traditional"
> > > device_model_stubdomain_override=0
> > > disk=[
> > > 'format=raw,backendtype=phy,backend=provider,vdev=xvdb,target=/dev/zvol/tank/test',
> > >
> > >
> > > 'file:/root/fbsd.iso,xvda,r,devtype=cdrom'
> AFAICT, if you use qemu-traditional stubdomains you should use hdb and
> hda instead of xvdb and xvda.
>
> > > ]
> > > boot='d'
> > >
> > > I get:
> > >
> > > # xl create consumer.conf
> > > Parsing config from consumer.conf
> > > libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: domain 47
> > > device model: spawn failed (rc=-3)
> > > libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device
> > > model did not start: -3
> > > libxl: error: libxl_dm.c:1475:kill_device_model: Device Model already
> > > exited
> > > libxl: error: libxl_device.c:1115:device_destroy_be_timeout_cb: timed
> > > out while waiting for /local/domain/31/backend/vbd/47/51728 to be removed
> > > libxl: error: libxl.c:1457:devices_destroy_cb: libxl__devices_destroy
> > > failed for 47
> > >
> > >
> > > And in qemu-dm-consumer.log:
> > > qemu-system-i386: -drive
> > > file=/dev/zvol/tank/test,if=ide,index=1,media=disk,format=raw,cache=writeback:
> > >
> > > could not open disk image /dev/zvol/tank/test: No such file or directory
> > >
> > >
> > > But when I use a stubdomain:
> > >
> > > #device_model_version="qemu-xen-traditional"
> > > device_model_stubdomain_override=1
> > >
> > > consumer DomU boots fine and I see /dev/xbd1 properly (and I'm sure its
> > > the tank/test zvol from provider DomU). However qemu-dm-consumer.log
> > > contains:
> > >
> > > frontend `/local/domain/49/device/vbd/51728' devtype `vbd' expected
> > > backend `/local/domain/0/backend/qdisk/49/51728' got
> > > `/local/domain/31/backend/vbd/49/51728', ignoring
> > > frontend `/local/domain/49/device/vbd/51728' devtype `vbd' expected
> > > backend `/local/domain/0/backend/qdisk/49/51728' got
> > > `/local/domain/31/backend/vbd/49/51728', ignoring
> Yes, not sure why, but qemu-traditional stubdomains were not able to
> use disks from driver domains. The following patch solved the problem
> for me, you should apply it to tools/qemu-xen-traditional-dir:
>
> ---
> diff --git a/xenstore.c b/xenstore.c
> index b0d6f77..44fe99d 100644
> --- a/xenstore.c
> +++ b/xenstore.c
> @@ -247,8 +247,11 @@ static void xenstore_get_backend_path(char **backend, 
> const char *devtype,
>       char *backend_dompath=0;
>       char *expected_backend=0;
>       char *frontend_backend_path=0;
> +    char *frontend_domid_path=0;
>       char *backend_frontend_path=0;
>       char *frontend_doublecheck=0;
> +    char *backend_domid_str=0;
> +    int backend_domid;
>       int len;
>       const char *frontend_idpath_slash;
>
> @@ -270,13 +273,21 @@ static void xenstore_get_backend_path(char **backend, 
> const char *devtype,
>                     frontend_path)
>           == -1) goto out;
>
> +    if (pasprintf(&frontend_domid_path, "%s/backend-id",
> +                  frontend_path)
> +        == -1) goto out;
> +
>       bpath = xs_read(xsh, XBT_NULL, frontend_backend_path, &len);
>
> +    backend_domid_str = xs_read(xsh, XBT_NULL, frontend_domid_path, &len);
> +    if (!backend_domid_str) goto out;
> +    backend_domid = atoi(backend_domid_str);
> +
>       /* now we must check that the backend is intended for use
>        * by this frontend, since the frontend's /backend xenstore node
>        * is writeable by the untrustworthy guest. */
>
> -    backend_dompath = xs_get_domain_path(xsh, domid_backend);
> +    backend_dompath = xs_get_domain_path(xsh, backend_domid);
>       if (!backend_dompath) goto out;
>
>       const char *expected_devtypes[4];
> @@ -336,6 +347,8 @@ static void xenstore_get_backend_path(char **backend, const 
> char *devtype,
>       free(frontend_backend_path);
>       free(backend_frontend_path);
>       free(frontend_doublecheck);
> +    free(frontend_domid_path);
> +    free(backend_domid_str);
>   }
>
>   static const char *xenstore_get_guest_uuid(void)
It's working, I can't believe it! Thank you so much!

For anyone who might be interested in this topic, I used a fresh 
Debian-based system (Wheezy 7.5 with 3.14.12-1~bpo70+1 kernel from 
backports) and compiled Xen 4.4.0 from sources (after unpacking the 
sources, applied Roger's patch in tools/qemu-xen-traditional directory). 
I used a FreeBSD 10 in livecd mode in the provider domU to create a zvol 
(nothing more is required, just like the wiki says). In consumer.conf I had:
device_model_stubdomain_override=1
disk=[
'format=raw,backendtype=phy,backend=provider,vdev=hda,target=/dev/zvol/pool0/testdev',
'file:/root/win.iso,hdb,r,devtype=cdrom'
]

That was enough to successfully install and boot FreeBSD 10 and Windows 
7 x64 in consumer domU. GPLPV drivers from EJB Digital (1.0.1100) worked 
flawlessly too.
Two things worth noting:
 - I didn't create a "true" storage driver domain - provider domU used 
an ordinary disk partition from dom0, no pci-passthrough was used;
 - FreeBSD 10 doesn't seem to like invalid target path.

Once again, I sincerely thank you for this solution. It's a dream come 
true for me :)
Best regards,
Kuba



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