thin provisioning in RHEV or on SAN ?
I'm considering finally starting to use thin provisioning somewhere, but am uncertain about where. Ideally I'd want to do it on the SAN only, so that we have one place to monitor for never running out-of-storage.
So, if I do thin provisioning on my SAN, how will this work with RHEV images? At which point does it get allocated?
- On storage domain creation?
- When we add a disk to a VM ?
- When VM creates a logical volume in it's VG?
- When VM creates a filesystem on top of the logical volume?
(btw: storage domain is accessed over iSCSI, VMs are mainly RHEL5/RHEL6 -- in case that matters)
-jf
Responses
You can see some details about it at https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html-single/Technical_Reference_Guide/index.html#sect-Technical_Reference_Guide-Storage_Functions-Provisioning_Storage
Especially section "3.3.2.2. Over-commitment"
Underlying storage is transparent to RHEV, so if you create a 100Gb LUN, that takes up 1Kb on the SAN, RHEV will see 100Gb, and use them normally. I would suggest combining sparse storage with online deduplication, and then using RHEV with fully provisioned images only. This way, sparseness and deduplication are offloaded to the array, and you do not need to worry about anything on the RHEV side, just monitor the SAN.
Without deduplication, thick provisioned VM disks will potentially get thick provisioned on the SAN, which pretty much beats the purpose of having the LUN sparse
It's a good question, but I'm afraid the answer is a bit complex, and it lies with what RHEV does under the hood for every action. Moreover, depending on the storage type, the action might be different. For example, provisioning a thick provisioned disk on block storage (FC/iSCSI/etc) means lvcreate, how a thin provisioned LUN responds to that is a question for the SAN vendor. With NFS, thick provisioned virtual disk image is created with qemu-img, and that fills the disk with zeroes. Zerofilling is guerranteed to remain thin on deduplicated storage, but what your specific storage will do, I, again, do not know - it might detect incoming zeroes and disregard them, or simply write them, effectively wasting space.
So if you really want to get to the bottom of this, you have two options - gather a list of all the common storage commands RHEV issues, contact the SAN vendor and inquire about the predicted behavior of a thin provisioned LUN when these commands are issued, or simply set up a demo setup, and see what happens for yourself
There is no single, or straight-forward answer (at this time) regarding how Thin Provisioning and storage reclamation works. This is not specific to RHEV, you will find the same dependencies on AIX, Solaris, etc...
There are numerous factors to consider when deploying Thin provisioning and the implications of the different components. I believe that the arrays need to work in conjunction with the Volume Manager to effectively "recover" the files which are released by the hosts.
If you create a file and popluate the file with data and then delete the file, we all know that it doesn't literally remove the data, it simply removes the pointers to the data. The array would not know that was the case unless there was some interaction with the host. HDS and Veritas have an ASL and you need to have a particular version installed for the Thin Provisioning and Storage Reclamation to work correctly. EMC needs a diferent ASL.
Like Dan mentioned, you would need to work with the storage Vendor to determine how their hardware attempts to do reclamation.