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 < [email protected]> 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:[email protected]] > *Sent:* Sunday, 7 August, 2016 10:55 > *To:* Simon Barrett <[email protected]> > *Cc:* [email protected] > *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 < > [email protected]> 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" <[email protected]> > 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 < > [email protected]> 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: > > > > [email protected]> 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 > > > > [email protected]> 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:* [email protected] [mailto:[email protected]] *On > Behalf Of *Simon Barrett > *Sent:* Friday, 5 August, 2016 10:25 > *To:* [email protected] > *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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/users > > > > >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
