search for: device_disk_add

...ng a configuration line that looks something like disk = [ "tap:vhd:/var/norm/pools/agentTest/d894b704-b890-488d-b66e-1422b2b9a7a5.vhd,xvda,w", "tap:vhd:/var/norm/pools/agentTest/70bd3927-0e27-4830-9bf0-5b66ba290547.vhd,xvdb,w" ] What I noticed happening in the code is that in device_disk_add the call to libxl__xs_transaction_commit returns rc=1 so the "for (;;)" loop just tries again. The problem though is that the blktap device was already created and assigned to a tapdisk process. So it will just leave that process hanging out there and allocated a new device on the secon...

...bxl.c index 572c2c6..550c63d 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -18,6 +18,8 @@ #include "libxl_internal.h" +#include <xen/io/protocols.h> + #define PAGE_TO_MEMKB(pages) ((pages) * 4) #define BACKEND_STRING_SIZE 5 @@ -2037,6 +2039,14 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, int rc; libxl_ctx *ctx = gc->owner; xs_transaction_t t = XBT_NULL; + const char *protocol = NULL; + char p[XEN_IO_PROTO_ABI_MAX_LEN+1]; + + libxl_domain_type type = libxl__domain_type(gc, domid); + if (type == LIBXL_DOMAIN_TYPE_INVALID)...

...y_tapdisk 66 type=aio:/mnt/test/disk disk=:/mnt/test/disk xendev01 ~ # mount -o remount,ro /mnt/test xendev01 ~ # /usr/sbin/xl block-attach nathannx "file:/mnt/test/disk" "xvdd4" DEBUG libxl__blktap_devpath 37 aio:/mnt/test/disk libxl: error: libxl.c:2149:device_disk_add: failed to get blktap devpath for 0xd3abd0 libxl: error: libxl.c:1727:device_addrm_aocomplete: unable to (null) device libxl_device_disk_add failed. I'm not sure why xen would care if the disk is writable? Would be nice to be able to mount these since many NFS storage arrays provide read...

...<nathan at gt.net> wrote: > xendev01 ~ # mount -o remount,ro /mnt/test > > > > xendev01 ~ # /usr/sbin/xl block-attach nathannx "file:/mnt/test/disk" > "xvdd4" > > DEBUG libxl__blktap_devpath 37 aio:/mnt/test/disk > > libxl: error: libxl.c:2149:device_disk_add: failed to get blktap devpath for > 0xd3abd0 > > libxl: error: libxl.c:1727:device_addrm_aocomplete: unable to (null) device > > libxl_device_disk_add failed. > > > > I'm not sure why xen would care if the disk is writable? Would be nice to be > able to mount these...

...w,vdev=xvda1,backend=storage,backendtype=tap,target=/root/domsi.img''] Where /root/domsi.img is path from Storage domain file system. While creating new domain I got this console log- root@suksha:~/domsikernel# xl create -c domsi Parsing config from domsi libxl: error: libxl.c:2125:device_disk_add: failed to get blktap devpath for 0x1f9e9e0 libxl: error: libxl_create.c:932:domcreate_launch_dm: unable to add disk devices Second try: then I did changed disk param to- disk = [''access=w,vdev=xvda1,backend=storage,target=/root/domsi.img''] And I got this console log -...

...w,vdev=xvda1,backend=storage,backendtype=tap,target=/root/domsi.img''] Where /root/domsi.img is path from Storage domain file system. While creating new domain I got this console log- root@suksha:~/domsikernel# xl create -c domsi Parsing config from domsi libxl: error: libxl.c:2125:device_disk_add: failed to get blktap devpath for 0x1f9e9e0 libxl: error: libxl_create.c:932:domcreate_launch_dm: unable to add disk devices Second try: then I did changed disk param to- disk = [''access=w,vdev=xvda1,backend=storage,target=/root/domsi.img''] And I got this console log -...

I think I posted this patch before, but it looks like it was in December 2012 (!). 1/1 libxl: introduce an option for disabling the non-O_DIRECT workaround Ideally it would go into 4.4, at least. Provided the corresponding qemu part has gone into qemu-xen, which I think it has. Can anyone confirm ?