On Thu, Mar 12, 2015 at 8:05 PM, Nathan March nathan@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 since many NFS storage arrays provide read only access to snapshots.

So by default, block-attach will set the access to a disk as read-write. If disk access is marked as read-write, the backend (in this case tapdisk) will attempt to open the file read-write; if this fails (as it will on read-only storage), the whole disk creation will fail. (This is true either of block-attach or domain creation.)

Normally you could fix this by adding ",ro" to your disk spec. But in the case of blktap, this option is ignored at the moment. :-/

I have, however, just taught xl to pay attention to this for blktap. I've got fixes to both this issue and the extra-tapdisk-process issue from the other thread in this local koji build:

http://cbs.centos.org/kojifiles/work/tasks/8801/8801/

If you could test those and let me know if it fixes your problem, I'd appreciate it. :-)

As an aside, you're using the old disk format; the new disk format looks more like this:

"vdev=hdc,format=raw,access=rw,target=/mnt/test/disk"

More info here:

/usr/share/doc/xen-doc-4.4.1/misc/xl-disk-configuration.txt

Thanks, -George