[ovirt-users] preallocated storage issue?
Fred Rolland
frolland at redhat.com
Mon Aug 8 08:14:38 UTC 2016
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 at 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 at redhat.com]
> *Sent:* Sunday, 7 August, 2016 10:55
> *To:* Simon Barrett <Simon.Barrett at tradingscreen.com>
> *Cc:* users at 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 at 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 at white-vdsd test]# du -h myfile.txt
> 1.0M myfile.txt
>
> [root at white-vdsd test]# ls -lh myfile.txt
> -rw-r--r-- 1 root root 1.0M Aug 7 12:39 myfile.txt
>
> [root at white-vdsd test]# qemu-img convert myfile.txt myfile2.txt
>
> [root at white-vdsd test]# ls -lh myfile2.txt
> -rw-r--r-- 1 root root 1.0M Aug 7 12:41 myfile2.txt
>
> [root at white-vdsd test]# du -h myfile2.txt
> 0 myfile2.txt
>
> [root at 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 at 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 at 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 at 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 at tradingscreen.com> wrote:
>
> Another example. This one was moved to a new storage domain
>
>
>
> root at 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 at 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 at 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 at ovirt.org [mailto:users-bounces at ovirt.org] *On
> Behalf Of *Simon Barrett
> *Sent:* Friday, 5 August, 2016 10:25
> *To:* users at 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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160808/88577a39/attachment-0001.html>
More information about the Users
mailing list