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

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

W dniu 2014-08-01 18:53, Roger Pau Monnà pisze:

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:



AFAICT, if you use qemu-traditional stubdomains you should use hdb and
hda instead of xvdb and xvda.


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
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

could not open disk image /dev/zvol/tank/test: No such file or directory

But when I use a stubdomain:


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

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,
          == -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_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:


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,

Xen-users mailing list



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