Eventually, the option of preallocated disk on NFS will not be available in
oVirt.
The underlying file systems in NFS are usually implementing sparse file.
There might even be a file system implementation that will ignore those
zeroes that we fill.
If you need a "real" preallocated disk, block storage will do the job for
you.
Regards,
Fred
On Mon, Aug 8, 2016 at 10:37 AM, Simon Barrett <
Simon.Barrett(a)tradingscreen.com> wrote:
Many thanks for the information and it does explain what I’m seeing.
Is this the expected result though or is it a known bug? If using qemu-img
to move images always results in a disk image that states it is
preallocated but does not allocate the space, how do I move preallocated
disk images? I know I can do the same within the VM and write a very large
file full of zeros to grow the image to full capacity on disk but is that
the correct approach?
Thanks again,
Simon
*From:* Fred Rolland [mailto:frolland@redhat.com]
*Sent:* Sunday, 7 August, 2016 10:55
*To:* Simon Barrett <Simon.Barrett(a)tradingscreen.com>
*Cc:* users(a)ovirt.org
*Subject:* Re: [ovirt-users] preallocated storage issue?
Simon,
What is happening is that when we create a preallocated disk on NFS, we
fill the file with zeros in order to "allocate" the space.
However, while copying the disk we use qemu-img that will ignore the zeros.
Quick way to demonstrate:
[root@white-vdsd test]# dd if=/dev/zero of=myfile.txt bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00172084 s, 609 MB/s
[root@white-vdsd test]# du -h myfile.txt
1.0M myfile.txt
[root@white-vdsd test]# ls -lh myfile.txt
-rw-r--r-- 1 root root 1.0M Aug 7 12:39 myfile.txt
[root@white-vdsd test]# qemu-img convert myfile.txt myfile2.txt
[root@white-vdsd test]# ls -lh myfile2.txt
-rw-r--r-- 1 root root 1.0M Aug 7 12:41 myfile2.txt
[root@white-vdsd test]# du -h myfile2.txt
0 myfile2.txt
[root@white-vdsd test]# qemu-img info myfile.txt
image: myfile.txt
file format: raw
virtual size: 1.0M (1048576 bytes)
disk size: 1.0M
[root@white-vdsd test]# qemu-img info myfile2.txt
image: myfile2.txt
file format: raw
virtual size: 1.0M (1048576 bytes)
disk size: 0
I hope this explains what you see.
Regards,
Fred
On Sun, Aug 7, 2016 at 11:13 AM, Simon Barrett <
Simon.Barrett(a)tradingscreen.com> wrote:
Storage is NFS. What logs would you like to see?
Many thanks.
Simon
On Sun, Aug 7, 2016 at 8:53 AM +0100, "Fred Rolland"
<frolland(a)redhat.com>
wrote:
Simon hi,
What storage type are you using in source and target storage domains ?
(NFS, ISCSI....)
Can you share the logs?
Thanks,
Fred
On Fri, Aug 5, 2016 at 6:37 PM, Simon Barrett <
Simon.Barrett(a)tradingscreen.com> wrote:
Another example. This one was moved to a new storage domain
root@ovirt_host1> qemu-img info dd6f25f6-7830-4024-915f-a20268797c34
image: dd6f25f6-7830-4024-915f-a20268797c34
file format: raw
virtual size: 200G (214748364800 bytes)
disk size: 5.0G
root@ ovirt_host1> cat dd6f25f6-7830-4024-915f-a20268797c34.meta
DOMAIN=53560d43-874a-49c5-9c5a-8b90487c79f8
VOLTYPE=LEAF
CTIME=1470305678
FORMAT=RAW
IMAGE=741976cd-d1cb-4031-bdbe-6a745dff16ef
DISKTYPE=2
PUUID=00000000-0000-0000-0000-000000000000
LEGALITY=LEGAL
MTIME=0
POOL_UUID=
SIZE=419430400
TYPE=PREALLOCATED
DESCRIPTION=
EOF
This one has not been moved:
root(a)ny2-lvb-066.mgt> qemu-img info 155f0d33-c280-4236-8d1e-fcb88f9a1242
image: 155f0d33-c280-4236-8d1e-fcb88f9a1242
file format: raw
virtual size: 90G (96636764160 bytes)
disk size: 90G
root(a)ny2-lvb-066.mgt> cat 155f0d33-c280-4236-8d1e-fcb88f9a1242.meta
DOMAIN=59bde2ff-e10d-477e-91c1-6355abff0999
CTIME=1464946639
FORMAT=RAW
DISKTYPE=2
LEGALITY=LEGAL
SIZE=188743680
VOLTYPE=LEAF
DESCRIPTION={"DiskAlias":"ny2-laa-010.prod_Disk1","DiskDescription":""}
IMAGE=82158182-81a4-458e-a41b-663756962666
PUUID=00000000-0000-0000-0000-000000000000
MTIME=0
POOL_UUID=
TYPE=PREALLOCATED
EOF
See the mismatch between “virtual size” and “disk size” on the one that
was moved.
TIA,
Simon
*From:* users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] *On
Behalf Of *Simon Barrett
*Sent:* Friday, 5 August, 2016 10:25
*To:* users(a)ovirt.org
*Subject:* [ovirt-users] preallocated storage issue?
If I create a preallocated disk for a VM, I see the disk image file
listing as the size I requested (100G):
cd /rhev/data-center/mnt/storage_host1:_vol_pa1__nas__01b__
oVirt__prod__01/53560d43-874a-49c5-9c5a-8b90487c79f8/images/
d97f7706-3662-40bf-9358-80e0dc51bff4
root@ovirt_host> ls -l
total 105064644
-rw-rw---- 1 vdsm kvm 107374182400 Aug 5 10:57 75c14559-e18f-4cc8-a3fe-
bc0de507720b
-rw-rw---- 1 vdsm kvm 1048576 Aug 5 10:57 75c14559-e18f-4cc8-a3fe-
bc0de507720b.lease
-rw-r--r-- 1 vdsm kvm 313 Aug 5 10:57 75c14559-e18f-4cc8-a3fe-
bc0de507720b.meta
and the corresponding space used on disk matches
root@ ovirt_host > du -sh *
101G 75c14559-e18f-4cc8-a3fe-bc0de507720b
1.1M 75c14559-e18f-4cc8-a3fe-bc0de507720b.lease
4.0K 75c14559-e18f-4cc8-a3fe-bc0de507720b.meta
If I then migrate that storage (while the VM is shutdown) to a new storage
domain, the size on disk does not match the allocated size. In this case
there is nothing in the disk yet so it shows as 0.
cd /rhev/data-center/mnt/storage_host2:_vol_pa1__ovirt__
uatprod/1f2c2b48-1e77-4c98-a6da-5dc09b78cead/images/
d97f7706-3662-40bf-9358-80e0dc51bff4
root@ ovirt_host> ls -l
total 1032
-rw-rw---- 1 vdsm kvm 107374182400 Aug 5 11:06 75c14559-e18f-4cc8-a3fe-
bc0de507720b
-rw-rw---- 1 vdsm kvm 1048576 Aug 5 11:06 75c14559-e18f-4cc8-a3fe-
bc0de507720b.lease
-rw-r--r-- 1 vdsm kvm 313 Aug 5 11:06 75c14559-e18f-4cc8-a3fe-
bc0de507720b.meta
root@ ovirt_host > du -sh *
0 75c14559-e18f-4cc8-a3fe-bc0de507720b
1.1M 75c14559-e18f-4cc8-a3fe-bc0de507720b.lease
4.0K 75c14559-e18f-4cc8-a3fe-bc0de507720b.meta
oVirt still lists the disk as preallocated in the GUI but it is in fact
thin provisioned.
I see the same issue if I clone a preallocated VM. The size on disk ends
up being the equivalent of a thin-provisioned disk. I also had the issue
when importing VM’s from an export domain when I had selected preallocated
in the import dialog box.
Is this a known issue? Should preallocated not mean preallocated on
physical disk?
Ovirt Engine is running 3.6.4.1-1.el6
The ovirt nodes are running:
OS Version: RHEL - 7 - 2.1511.el7.centos.2.10
Kernel Version: 3.10.0 - 327.4.5.el7.x86_64
KVM Version: 2.3.0 - 31.el7_2.7.1
LIBVIRT Version: libvirt-1.2.17-13.el7_2.2
VDSM Version: vdsm-4.17.23.2-0.el7.centos
SPICE Version: 0.12.4 - 15.el7
GlusterFS Version: [N/A]
CEPH Version: librbd1-0.80.7-3.el7
Many thanks,
Simon
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users