[one-users] Thin provisioning and qcow2
Hello, I want to use thin provisioning for my images and therefore I use the qcow2 format but for some reason ONE does not use sparse file copy / move operations. Here is what I did: I have a datastore with qcow2 driver: oneadmin@one01:~$ onedatastore show 101 DATASTORE 101 INFORMATION ID : 101 NAME : rz1-01-image USER : oneadmin GROUP : oneadmin CLUSTER: RZ1 TYPE : IMAGE DS_MAD : fs TM_MAD : qcow2 BASE PATH : /var/lib/one/datastores/101 DISK_TYPE : FILE DATASTORE CAPACITY TOTAL: : 6.5T FREE: : 6.3T USED: : 132.9G LIMIT: : - PERMISSIONS OWNER : um- GROUP : u-- OTHER : --- DATASTORE TEMPLATE BASE_PATH=/var/lib/one/datastores/ CLONE_TARGET=SYSTEM DISK_TYPE=FILE DS_MAD=fs LN_TARGET=NONE TM_MAD=qcow2 TYPE=IMAGE_DS IMAGES ... I created a new empty image: oneadmin@one01:~$ qemu-img create -f qcow2 -o preallocation=metadata debian.qcow2 4G This file takes only a few KB of disk space: oneadmin@one01:$ qemu-img info debian.qcow2 image: debian.qcow2 file format: qcow2 virtual size: 4.0G (4294967296 bytes) disk size: 784K cluster_size: 65536 So I import it into the Datastore with driver qcow2: oneadmin@one01:~$ oneimage create -d 101 --name debian --path ~/debian.qcow2 --prefix vd --type OS --driver qcow2 But as you can see after the import the file is 4GB in size: oneadmin@one01:~$ oneimage show debian IMAGE 28 INFORMATION ID : 28 NAME : debian USER : oneadmin GROUP : oneadmin DATASTORE : rz1-01-image TYPE : OS REGISTER TIME : 02/02 14:35:42 PERSISTENT : No SOURCE : /var/lib/one/datastores/101/0b96c87ba5445c347ad407bb1f4950ff PATH : /var/lib/one/debian.qcow2 SIZE : 4G STATE : rdy RUNNING_VMS: 0 PERMISSIONS OWNER : um- GROUP : --- OTHER : --- IMAGE TEMPLATE DEV_PREFIX=vd DRIVER=qcow2 VIRTUAL MACHINES oneadmin@one01:~$ qemu-img info /var/lib/one/datastores/101/0b96c87ba5445c347ad407bb1f4950ff image: /var/lib/one/datastores/101/0b96c87ba5445c347ad407bb1f4950ff file format: qcow2 virtual size: 4.0G (4294967296 bytes) disk size: 4.0G cluster_size: 65536 I think this is due to the underlying copy operation does not handle qcow2 / sparse files correctly. You can reproduce same failures in bash: If you cp the file everything is fine but if you do a rsync or scp the file has its virtual size afterwards. For rsync there is the switch -S to correctly handle sparse files, there is no such switch for scp tough. What am I doing wrong? Am I using the right way to create empty qcow2 / thin provisioned images? I want to create a vm and do a pxe install afterwards (works fine I only have the thin provisioning problem). I also tried to create an empty datablock using driver qcow2 and fs type ext4 but in that way I get a raw file. That one seems to be thin provisioned but I think I have some advantages if I use qcow2 (copy on write / snapshot performance). Thank you very much any help is very appreciated, Nils Schröder CEWE Stiftung Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg HR B 208214; Persönlich haftende geschäftsführende und vertretungsberechtigte Gesellschafterin: Neumüller CEWE COLOR Stiftung, Oldenburg Stiftungsverzeichnis der rechtsfähigen Stiftungen des bürgerlichen Rechts im Bezirk der Regierungsvertretung Oldenburg Nummer 15(034); Vorstand: Dr. Rolf Hollander, Vorsitzender; Dr. Reiner Fageth, Carsten Heitkamp, Andreas F.L. Heydemann, Dr. Olaf Holzkämper, Thomas Mehls, Harald H. Pirwitz, Frank Zweigle; Geschäftsführung: Patrick Berkhouwer Aufsichtsrat: Otto Korte (Vorsitzender) UST ID-Nr. DE815453806; St.-Nr. 64/200/38999; GLN 40 04468 0 4 ___ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
Re: [one-users] Thin provisioning and qcow2
This is my datastore definition for my qcow2-based image store. I am not using the qcow2 TM_MAD to move the image from one place to the other but I do declare it as the driver for all the images. (this is a shared image store using NFS). In this mode it brings a separate copy of my 2GB compressed image to the node every time a VM is launched, rather than forking off of the existing copy, but it does not expand the qcow2..in other words what starts as 2GB stays 2GB. The same thing works if you are using TM_SSH, i.e that transfer manager does not expand the image. Usually if you look in to the numberd VM log that is made when the VM is launched or the image is stored you can figure out what is going on and which driver is being called. Steve Timm DATASTORE 102 INFORMATION ID : 102 NAME : cloud_images USER : oneadmin GROUP : oneadmin CLUSTER: cloudworker TYPE : IMAGE DS_MAD : fs TM_MAD : shared BASE PATH : /var/lib/one/datastores/102 DISK_TYPE : FILE DATASTORE CAPACITY TOTAL: : 7T FREE: : 2.1T USED: : 39G LIMIT: : - PERMISSIONS OWNER : um- GROUP : u-- OTHER : --- DATASTORE TEMPLATE BASE_PATH=/var/lib/one/datastores/ CLONE_TARGET=SYSTEM DATASTORE_CAPACITY_CHECK=NO DISK_TYPE=FILE DS_MAD=fs LN_TARGET=NONE TM_MAD=shared TYPE=IMAGE_DS IMAGES 4 5 [root@fclheadgpvm01 ~]# From: Users [users-boun...@lists.opennebula.org] on behalf of Schroeder, Nils [nils.schroe...@cewe.de] Sent: Monday, February 02, 2015 9:47 AM To: users@lists.opennebula.org Subject: [one-users] Thin provisioning and qcow2 Hello, I want to use thin provisioning for my images and therefore I use the qcow2 format but for some reason ONE does not use sparse file copy / move operations. Here is what I did: I have a datastore with qcow2 driver: oneadmin@one01:~$ onedatastore show 101 DATASTORE 101 INFORMATION ID : 101 NAME : rz1-01-image USER : oneadmin GROUP : oneadmin CLUSTER: RZ1 TYPE : IMAGE DS_MAD : fs TM_MAD : qcow2 BASE PATH : /var/lib/one/datastores/101 DISK_TYPE : FILE DATASTORE CAPACITY TOTAL: : 6.5T FREE: : 6.3T USED: : 132.9G LIMIT: : - PERMISSIONS OWNER : um- GROUP : u-- OTHER : --- DATASTORE TEMPLATE BASE_PATH=/var/lib/one/datastores/ CLONE_TARGET=SYSTEM DISK_TYPE=FILE DS_MAD=fs LN_TARGET=NONE TM_MAD=qcow2 TYPE=IMAGE_DS IMAGES ... I created a new empty image: oneadmin@one01:~$ qemu-img create -f qcow2 -o preallocation=metadata debian.qcow2 4G This file takes only a few KB of disk space: oneadmin@one01:$ qemu-img info debian.qcow2 image: debian.qcow2 file format: qcow2 virtual size: 4.0G (4294967296 bytes) disk size: 784K cluster_size: 65536 So I import it into the Datastore with driver qcow2: oneadmin@one01:~$ oneimage create -d 101 --name debian --path ~/debian.qcow2 --prefix vd --type OS --driver qcow2 But as you can see after the import the file is 4GB in size: oneadmin@one01:~$ oneimage show debian IMAGE 28 INFORMATION ID : 28 NAME : debian USER : oneadmin GROUP : oneadmin DATASTORE : rz1-01-image TYPE : OS REGISTER TIME : 02/02 14:35:42 PERSISTENT : No SOURCE : /var/lib/one/datastores/101/0b96c87ba5445c347ad407bb1f4950ff PATH : /var/lib/one/debian.qcow2 SIZE : 4G STATE : rdy RUNNING_VMS: 0 PERMISSIONS OWNER : um- GROUP : --- OTHER : --- IMAGE TEMPLATE DEV_PREFIX=vd DRIVER=qcow2 VIRTUAL MACHINES oneadmin@one01:~$ qemu-img info /var/lib/one/datastores/101/0b96c87ba5445c347ad407bb1f4950ff image: /var/lib/one/datastores/101/0b96c87ba5445c347ad407bb1f4950ff file format: qcow2 virtual size: 4.0G (4294967296 bytes) disk size: 4.0G cluster_size: 65536 I think this is due to the underlying copy operation does not handle qcow2 / sparse files correctly. You can reproduce same failures in bash: If you cp the file everything is fine but if you do a rsync or scp the file has its virtual size afterwards. For rsync there is the switch -S to correctly handle sparse files, there is no such switch for scp tough. What am I doing wrong? Am I using the right way to create empty qcow2 / thin provisioned images? I want to create a vm and do a pxe install afterwards (works fine I only have the thin provisioning problem). I also tried to create an empty datablock using driver qcow2 and fs type ext4 but in that way I get a raw file. That one seems to be thin provisioned but I think I have some advantages if I use qcow2 (copy on write / snapshot performance). Thank you very much any help is very appreciated, Nils Schröder CEWE Stiftung Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg HR B 208214; Persönlich haftende geschäftsführende und
