On Thu, Mar 12, 2015 at 8:05 PM, Nathan March <nathan@xxxxxx> 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 _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
