Description of problem: Version-Release number of selected component (if applicable): glusterfs-3.3.0.5rhs-40.el6rhs.x86_64 libvirt-0.9.10-21.el6_3.7.x86_64 qemu-kvm-0.12.1.2-2.295.el6_3.10.x86_64 How reproducible: Always Steps to Reproduce: 1. Create qcow2 image with preallocation=metadata option[1] on a gluster mount[3] and try to fallocate it. Actual results: fallocation fails with operation not supported message and the disk size is just 1.8M. However, this works as expected on the host xfs filesystem[2]. And VM installation fails when this image is specified. Expected results: creating gcow2 image with preallocation=metadata option should be successful. Additional info: [1] [root@rhs-gp-srv11 replicate]# qemu-img create -f qcow2 -o preallocation=metadata rhsvm4-20130115.0.qcow2 10G Formatting 'rhsvm4-20130115.0.qcow2', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536 preallocation='metadata' [root@rhs-gp-srv11 replicate]# [root@rhs-gp-srv11 replicate]# fallocate -l 10737418240 rhsvm4-20130115.0.qcow2 fallocate: rhsvm4-20130115.0.qcow2: fallocate failed: Operation not supported <<<<<<<<<< [root@rhs-gp-srv11 replicate]# [root@rhs-gp-srv11 replicate]# qemu-img info rhsvm4-20130115.0.qcow2 image: rhsvm4-20130115.0.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 1.8M <<<<<<<<<<< cluster_size: 65536 [root@rhs-gp-srv11 replicate]# [2] [root@rhs-gp-srv11 rhsvm4-20130115.0]# qemu-img create -f qcow2 -o preallocation=metadata rhsvm4-20130115.0.qcow2 10G Formatting 'rhsvm4-20130115.0.qcow2', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536 preallocation='metadata' [root@rhs-gp-srv11 rhsvm4-20130115.0]# fallocate -l 10737418240 rhsvm4-20130115.0.qcow2 [root@rhs-gp-srv11 rhsvm4-20130115.0]# qemu-img info rhsvm4-20130115.0.qcow2 image: rhsvm4-20130115.0.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 17G cluster_size: 65536 [root@rhs-gp-srv11 rhsvm4-20130115.0]# [3] [root@rhs-gp-srv11 ~]# mount /dev/mapper/VolGroup-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") /dev/sda1 on /boot type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /dev/mapper/sdm_lvm_grp-sdm_vol1 on /home/rhsvms/rhsvm1 type xfs (rw) /dev/mapper/sdl_lvm_grp-sdl_vol1 on /home/rhsvms/rhsvm2 type xfs (rw) /dev/mapper/sdn_lvm_grp-sdn_vol1 on /home/rhsvms/rhsvm3 type xfs (rw) rhsvm1:replicate on /vmstore/replicate type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072) rhsvm1:distribute on /vmstore/distribute type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072) /dev/mapper/sdk_lvm_grp-sdk_vol1 on /home/rhsvms/rhsvm4-20130115.0 type xfs (rw) [root@rhs-gp-srv11 ~]# [4] # df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root 29G 5.7G 22G 21% / tmpfs 24G 0 24G 0% /dev/shm /dev/sda1 485M 59M 401M 13% /boot /dev/mapper/sdm_lvm_grp-sdm_vol1 450G 134G 317G 30% /home/rhsvms/rhsvm1 /dev/mapper/sdl_lvm_grp-sdl_vol1 450G 83G 368G 19% /home/rhsvms/rhsvm2 /dev/mapper/sdn_lvm_grp-sdn_vol1 100G 83G 18G 83% /home/rhsvms/rhsvm3 rhsvm1:replicate 50G 1.1G 49G 3% /vmstore/replicate rhsvm1:distribute 150G 26G 125G 17% /vmstore/distribute /dev/mapper/sdk_lvm_grp-sdk_vol1 450G 17G 434G 4% /home/rhsvms/rhsvm4-20130115.0
Created attachment 679355 [details] strace while creating qcow2 image on base filesystem strace while creating qcow2 image with preallocation=metadata option on base filesystem
Created attachment 679357 [details] strace while creating qcow2 image on fuse mount strace while creating qcow2 image with preallocation=metadata option on fuse mount.
Created attachment 679369 [details] Additional setup and partitioning info
not an 'high' priority as not an issue with RHEV :-)
This fails on native fuse mount due to non-support of ioctl on native mounts. ioctl(3, CDROM_DRIVE_STATUS, 0x7fffffff) = -1 ENOSYS (Function not implemented) Needs investigation whether bringing in support for ioctl on fuse-bridge is required.
Removing rhs-2.0+ tag as ioctl support is not present with upstream fuse too.
I have few info to add to this bug, 1. This happens only in fuse mounted , replicated volume 2. This happens only when trying to create qcow2 image with an option preallocation=metadata
Targeting for Arches.
The product version of Red Hat Storage on which this issue was reported has reached End Of Life (EOL) [1], hence this bug report is being closed. If the issue is still observed on a current version of Red Hat Storage, please file a new bug report on the current version. [1] https://rhn.redhat.com/errata/RHSA-2014-0821.html