[CentOS-virt] Can't block-attach a file on a read only volume?

George Dunlap dunlapg at umich.edu
Fri Mar 13 16:27:49 UTC 2015


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


More information about the CentOS-virt mailing list