HPE Storage Users Group

We are planning to make a new data server. This server will be a virtual server (vmware 5).
The virtual volume we have made for the data partition is a thin provisioned virtual volume with zero detect turned on.
What are the pro's and con's of presenting this disk while using raw device mapping, and what are the pro's and con's of presenting this disk as a vmware datastore.
If we choose to present the disk as a datastore should we format it as a thin provisioned datastore or an eager zeroed datastore.

Thanks in advance.

What storage frame do you have and what version of Inform is it running?

ESX 5.0 and Inform 3.1.1 are natively supported., no VAAI plugin required. Since this uses the T10-UNMAP command instead of the older method of WRITE-SAME to zero out the data, I question the use of the zero_detect flag. I recommend you consult support for clarification, please let me know what they tell you! =)

RDM vs VMFS is a Vmware topic that gets debated on VMware forums, and will undoubtably have much more information. RDMs add complexity to your ESX config, and occupy a LUN#, something you are limited to 255 of in your cluster, however each physical LUN gets it's own queue depth. It could be considered a waste of a LUN# to have a small 20g RDM for a host if it does not explicitly need an RDM. In our large 18 node ESX farms, our preference is for VMFS datastores. We do have a few 1-offs that are RDM, typically for a Windows Clustered guest node. There are best practices to how many ESX hosts and how many guests should share a single VMFS Datastore at one time... so calculate out your average VM size, apply those best practices to figure out an ideal size for your VMFS Datastores. We standardized on 1TB Thin Provisioned LUNs for our ESX farm.

When you create data stores with ESX 5. They should be VMFS5. Creating the Virtual Disks is where you will see the options for Thin, Thick Lazy or Thick Eager. Wether you use thick or thin is a conversation/preference between the storage and VM admins. My VM admin doesn't like to manage over provisioning of his data stores so he chooses thick. Lazy vs Eager is probably a security vs convenience issue. Lazy will quickly build your virtual lun, but old data from a deleted VM that used to live there may be recovered with undelete utilities. Eager will zero the whole virtual lun out first, so that the new VM gets a squeaky clean lun.

Consider your Thin provisioning licensed capacity on the 3par when you make the decision to use Thick or Thin inside VM. For example, if you do not have very much licensed thin capacity, you may decide to assign Fully provisioned luns to VMware and let ESX do its own thin... leaving limited 3PAR licensed thin capacity for your physical boxes.

Hope this helps!

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

We decided to go for a RDM Fully Provisioned lun. We have more then enough space free so decided to not use thin provisioning. Since the number of LUN's is not a problem in our VMWare cluster we decided to just go for RDM and leave VMware out of this.
We made a 2TB TP zero-detect RDM lun, but when we tried to use SDELETE we calculated it would take about 10 days to complete..... That made us decide to go for a fully provisioned lun.

Did you understand the part about T10-unmap with ESX 5 and Inserve 3.1.1... I don't understand the zero detect option being enabled if thats what your running.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

I understand what you meant with the T10-unmap command. It is to reclaim "dead" space.
As I said we have a greatly oversized system so we decided to just go for en fully provisioned lun.
Now we dont have to worry about any commands or programs we have to run every now and then.

I was just wondering why test ZERO_DETECT and SDELETE for a 10 hour test when you're using ESX 5? the T10 stuff supersedes that old method and is much much faster... dare I say instant. But I agree, if you don't need/want thin provisioning... then why add the complexity

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

Also, another important fact to consider when sizing your VMFS datastores is the Block Size you'll use since it will restrict maximum Virtual disk file size.

Good Morning,

I see this is kind of old but I'm about to do the same thing.... Does means of backup not play a huge role in this decision?

I need to put a 5 TB sql DB on VM.... How do I back that up if not via some sort of array snap?

"Lazy vs Eager is probably a security vs convenience issue. Lazy will quickly build your virtual lun, but old data from a deleted VM that used to live there may be recovered with undelete utilities. Eager will zero the whole virtual lun out first, so that the new VM gets a squeaky clean lun."

That statement is not true. ESXi will still zero out the page on first use, even if yo attemt a read on a lazy zeroed vmdk.
Perhaps you are mixing up the rather embarrassing incident with Amazon's disk data leakage with VMware?

Thanks for the correction on Lazy zeroing.

Impact on backups... that all depends on your backup software of choice.

Currently we are using Symantec Netbackup w/Dedupe which leverages ESX "Change Block Tracking" and ESX snapshots to do backups. The first backup is a monster, but the rest are tamed by CBT, Synthetic fulls, and single pass backups.

The new VVOLS in ESX 6 should improve this dramatically.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.