Welcome to the Business Critical Apps Blog. This week we will be publishing a few blogs that focus on virtualizing Microsoft Tier-1 applications. This may include discussion around a specific application like MS SQL or Exchange or some more generalized discussion around topics we get the most questions on when talking to customers. If you're responsible for virtualizing Microsoft Tier-1 apps check in throughout the week and take a look at what we've got going on. If this is your first visit to this blog check out our archives for tips on virtualizing MS Exchange, SQL and even some Oracle, SAP and Java discussions. Join in on the conversation by asking a question or making a comment. On to the first topic for the week: storage!
Virtualization of I/O intensive applications is nothing new. Traditionally the virtualization of these applications involved provisioning raw-device mappings over virtual disk files, whether warranted or not. VMware has proven the performance of VMFS to be on par with that of raw-device mappings as far back as ESX 3.0.1 (Performance Characterization of VMFS and RDM Using a SAN). While technically required for some configurations (MSCS clustering, hardware-based VSS, etc.), deploying raw-device mappings is no longer the de facto standard for virtualized I/O intensive applications.
When creating a new virtual disk (VMDK) there are a few options for how the virtual disk is created and when the space is allocated. Understanding the types of disk provisioning methods available and when to use them can help you provide the best level of performance for your business critical apps. The three types of disk provisioning are described below:
- Thick provisioned lazy zeroed – The virtual disk is allocated all of its provisioned space and immediately made accessible to the virtual machine. A lazy zeroed disk is not zeroed up front which makes the provisioning very fast. However, because each block is zeroed out before it is written to for the first time there is added latency on first write.
- Thick provisioned eager zeroed (Recommended for I/O intensive workloads) – The virtual disk is allocated all of its provisioned space and the entire VMDK file is zeroed out before allowing the virtual machine access. This means that the VMDK file will take longer to become accessible to the virtual machine, but will not incur the additional latency of zeroing on first write. For this reason the recommendation when deploying an I/O intensive application on VMFS is to use this provisioning method.
- Thin provision – This method provides quick access to the virtual disk and increases storage utilization by allocating disk space on demand.
Now that we've established the differences between the provisioning types, let's discuss the various ways we can create an eager zeroed thick disk, how we can check if a virtual disk is eager zeroed thick, and how we can eager zero a disk after the fact.
How can I create a virtual disk as eagerzeroedthick?
- If using the vSphere 4 client you can check the Support clustering features such as Fault Tolerance box during disk creation. Checking this box won't enable FT for your VM, but it will format the VMDK as eagerzeroedthick as this is a requirement for FT.
- If using the vSphere 5 client you are presented with three options during disk creation; select the Thick Provision Eager Zeroed radio button.
I'm not sure how my virtual disks were created, how can I check?
Fortunately we can check if a virtual disk was created as eagerzeroedthick. To do so we can use vmkfstools –D (capital "D") against the VMDK in question (direct the command to the <vm_name>-flat.vmdk file):
vmkfstools -D <vm_name>-flat.vmdk
The output of this command will look similar to the output below. We're interested in TBZ in the last line. This refers to the number of blocks in the disk file To Be Zeroed. A TBZ of zero indicates an eagerzeroedthick VMDK, otherwise it is zeroedthick or lazy zeroed as in our example below.
Lock [type 10c00001 offset 9345024 v 30, hb offset 3293184
gen 11, mode 1, owner 4ea9d387-964b13c3-7f81-001a4be8eae0 mtime 49198 nHld 0 nOvf 0]
Addr <4, 2, 19>, gen 25, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 1073741824, nb 128 tbz 128, cow 0, newSinceEpoch 0, zla 1, bs 8388608
For more information on determining whether or not a VMDK is eagerzeroedthick or zeroedthick refer to VMware KB article Determining if a VMDK is zeroedthick or eagerzeroedthick.
Oops, I didn't eagerzerothick my virtual disk during creation, what can I do?
There are a few ways to zero out your existing virtual disk.
Using vmkfstools you can use the -k option to zero out un-zeroed blocks while maintaining existing data. This is the best option if you've already started populating the disk with data as the data will not be touched. Direct the command to the <vm_name>.vmdk file.
Vmkfstools –k <vm_name>.vmdk
Note: This method requires the virtual machine to be powered off or the virtual disk to be removed from the virtual machine.
If powering off the virtual machine or using hot-remove to disconnect the virtual disk is not an option and if there is NO data on the virtual disk you may reformat the volume from within Windows by unchecking the Quick Format option. This process removes files from the volume and scans the entire volume for bad sectors, effectively causing all blocks to be touched and zeroed.
Enabling Fault Tolerance for a VM requires that the VMDK be zeroed out. If your virtual machine has only one vCPU you can temporarily enable FT and the process will make sure that all virtual disks are eagerzeroedthick. Once the disk has been prepared you can disable FT. This method also preserves existing data.
Hopefully this has given you a better look at why we recommend using eager zeroed thick disks for IO intensive applications as well as how to create new disks, check existing disks, and convert existing virtual disks to the eagerzeroed format.
As always, we look forward to hearing from you so please join the discussion!
Alex Fontana, Sr. Solutions Architect