The vSphere 4 platform introduced loads of new features that are quickly being adopted by VMware customers. Many of those features are included in the network and storage stacks. The word’s out. Still… after several conversations with people about the product, I’ve noticed they haven’t really discovered the full potential of some of the new features added to the VMkernel. Hopefully, this will get you to know it!
Change Block Tracking (CBT) is a new VMkernel feature that keeps track of the storage blocks of virtual machines as they change over time. Because of this features a couple of functions are way more efficient on VMware’s vSphere 4 platform than previous Virtual Infrastructure 3.
The VMkernel keeps track of block changes on virtual machines, which enhances the backup process for applications that have been developed with VMware’s new vStorage APIs. The VMkernel’s Change Block Tracking (CBT) enhances VMware’s Storage VMotion because the process no longer consumes double the amount of resources per virtual machine. This allows a larger number of simultaneous migrations. Smooth precision.
On the storage side, things have been streamlined to a beautiful degree: VMware’s third party software partners no longer need worry about writing code that first finds what blocks have changed. Instead they can write code to ask the VMkernel for that information. Much less effort on your part! It works by using VMware’s APIs to send queries to the VMkernel, which in turn, produce the information about the latest data since the last backup function.
For Storage VMotion, when virtual machines are being migrated, all of the files for the virtual machines are copied from one datasource to another (except, of course, the data disk from the source location). At this point the VMkernel then enables Change Block Tracking on the virtual machines disks to keep track on the disk while recording which disk regions include data. The change data can reside in memory or a bitmap files that reside in memory.
The migration process pre-copies the virtual machine’s disk and swap file from the source datastore to the new destination. In that time , the virtual machine may be writing to its own disk and regions of the disk can change and therefore resent (Not sure what this means?). This is where Change Block Tracking comes in.
The migration process first copies the contents of the entire disk to the destination; this is the first pre-copy iteration. It then queries the changed block tracking module to determine what regions of the disk were written to during the first iteration. The migrations process performs a second iteration of pre-copy, only copying those regions that were changed during the first iteration. Typically the number of changed regions is significantly smaller than the total size of the disk, so the second iteration takes significantly less time.
The server continues pre-copying until the amount of modified data is small enough to be copied very quickly. After that, the servers use a fast suspend/resume on the virtual machine. Fast suspend/resume does exactly what its name implies: the virtual machine is quickly suspended and resumed, with the new virtual machine process using the destination virtual machine home and disks. Before the servers allow new virtual machines to resume, the final changed regions of the source disk are copied over to the destination so that the destination disk image is identical to the source. Once the virtual machine is running on the destination datastore, the servers remove the source home and disks of the virtual machine.
The Change Block Tracking feature makes all that data transfer process much more efficient and better for everyone, customers and third party partners alike.
Although Change Block Tracking works exclusively on products that are part of the vSphere 4 platform, it’s important to note that CBT is not storage specific to any storage technology in particular. It works on all VMware supported types of datastores in thick or thin provision formats with the exclusion of RDM’s in physical mode.
You should also take note of CBTs default settings: Change Block Tracking is not enabled by default because it introduces a small amount of overhead on the virtual machines that it’s enable for. The ball is placed on your court to decide if the small difference in speed is worth leaving the default in place.
The feature is enabled automatically by applications such as VMware Data Recovery, Veeam Backup & Replication, and others that are Change Block Tracking aware and are compatible with the vSphere 4 platform. Change Block Tracking can also be enabled via the vSphere SDK or even manual as shown on the screenshot below. In order for this to work all virtual machines must be using hardware version 7.
To enable CBT manually, follow these steps:
Edit the settings of the virtual machines. Select the Options tab, then under Advanced settings select General and then click Configuration Parameters button.
Click the add new row button to add the parameter that enables the feature ctkEnabled as the feature name, then make the value true.
Now for every disk configured on the virtual machine add a new row entry with scsi#:#.ctkEnabled replace the # signs with the controller/disk number for each disk, then add the true for the rows then save it.
The virtual machines will go through a quiecing cycle in order for the settings to take effect. It will happen during certain operations for example when the virtual machine is power on/off, suspend/resume, create/delete snapshot. In those process the disks are open to allow a the change tracking filter to be placed in the storage stack for virtual machines where the feature was enabled. The Change Block Tracking feature will store the information about changed blocks for a virtual disk in a file with the following extension -ctk.vmdk. This file is created in every virtual machines directory.
The size of the -ctk.vmdk file is static, and it doesn’t grow past the initial size unless the size of the virtual disks are changed. File size changes based upon the size of a virtual disk which is around .5MB for every 10 GB for the size if a virtual disk. The state of each file is located here for and each block is stored for tracking purposes using sequence numbers that will let queries from applications if there has been any modification to a block or not.
Change Block Tracking improves the speed of for backing up and restoring virtual machines, and it’s also the technology that enhances the new way Storage VMotion migrations are done. Make sure to take a look at the VMware Software Comparability list and see if the backup product that you use is compatible and capable of taking advantage of Change Block Tracking. You may find that it was a feature worth waiting for as well as another entree into VMware’s world of solutions.
For more information on the Change Block Tracking features of ESX checkout Eric Seibert’s posting on this topic over at SearchVMware.com, from Virtualization Pro. Eric’s posting covers areas in more details that are not found here. This post is very similar to what Eric covers in his post, but punching clouds did not plagiarized the good work done by Eric Seibert and its associates.
Also check out Duncan Epping’s post over at yellow-bricks.com for more information on CBT. : )
Today VMware released the new version of their application virtualization platform. The new version ThinApp 4.5 is said to speed up the migration process to Windows 7 as much as 40 % for customers who are planning upgrading to Microsoft latest desktop operating system.
