Nathan March
2015-Mar-12 20:05 UTC
[CentOS-virt] Can't block-attach a file on a read only volume?
Hi All, One more weird issue, this works on old xen but fails on 4.4: xendev01 ~ # mkdir /mnt/test xendev01 ~ # mount -t tmpfs - /mnt/test xendev01 ~ # dd if=/dev/null of=/mnt/test/disk seek=100M bs=1 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000201809 s, 0.0 kB/s xendev01 ~ # /usr/sbin/xl block-attach nathannx "file:/mnt/test/disk" "xvdd4" DEBUG libxl__blktap_devpath 37 aio:/mnt/test/disk DEBUG libxl__blktap_devpath 40 /dev/xen/blktap-2/tapdev20 xendev01 ~ # xl block-detach nathannx 51764 DEBUG libxl__device_destroy_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 only access to snapshots. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20150312/94efcce9/attachment-0001.html>
George Dunlap
2015-Mar-13 16:27 UTC
[CentOS-virt] Can't block-attach a file on a read only volume?
On Thu, Mar 12, 2015 at 8:05 PM, Nathan March <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 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
Nathan March
2015-Mar-13 17:58 UTC
[CentOS-virt] Can't block-attach a file on a read only volume?
> 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. :-)Confirmed, both issues are fixed. Thanks! Any plans to push those packages to main mirrors? - Nathan
Reasonably Related Threads
- Can't block-attach a file on a read only volume?
- Tapdisk processes being left behind when hvm domu's migrate/shutdown
- libxl device_disk_add orphans blktap devices on transaction error
- [PATCH] libxl: attempt to cleanup tapdisk processes on disk backend destroy
- Can't block-attach a file on a read only volume?