Everything you need to know about vSphere and data storage


This article can also be found in the Premium Editorial Download "IT in Europe: Data dedupe: A natural fit with backup."

Download it now to read this article plus other related content.

Paravirtualized SCSI adapters

Paravirtualization is a technology available for certain operating systems that use a special driver to communicate directly with the hypervisor. Without paravirtualization the guest OS doesn't know about the virtualization layer and privileged calls are trapped by the hypervisor using binary translation.

Paravirtualization allows for greater throughput and lower CPU utilization for virtual machines, and is useful for disk I/O-intensive applications. Paravirtualized SCSI adapters are separate storage adapters that can be used for non-primary OS partitions and can be enabled by editing a VM's settings and enabling the paravirtualization feature.

This may sound similar to VMDirectPath, but the key difference is that paravirtualized SCSI adapters can be shared by multiple VMs on host servers and don't require dedicating a single adapter to a single virtual machine.

VMDirectPath for storage I/O devices

VMDirectPath is similar to paravirtualized SCSI adapters where a VM can directly access host adapters and bypass the virtualization layer for better throughput and reduced CPU utilization. But with VMDirectPath you must dedicate an adapter to a VM and it can't be used by any other virtual machines on that host.

VMDirectPath is available for specific models of both network and storage adapters, however, only the network adapters are currently fully supported

Requires Free Membership to View

in vSphere; storage adapters only have experimental support. Like PVSCSI adapters, VMDirectPath can be used for VMs that have very high storage or network I/O requirements like database servers. VMDirectPath enables virtualization of workloads that you might previously have kept physical. A downside to using VMDirectPath is that you can't use features like VMware VMotion and Distributed Resource Scheduler (DRS).

Storage VMotion enhancements

While VMotion moves a running VM from one host to another leaving the virtual machine location intact, Storage VMotion (SVMotion) keeps the VM on the same host and only changes the VM's storage location. SVMotion was first introduced in ESX Version 3.5, but was only available as a command line utility. In vSphere, it's integrated in the vSphere Client, allowing quick and easy SVMotion moves. In addition, SVMotion now allows thick-to-thin disk conversion (and vice versa).

SVMotion can also be used to re-shrink a thin disk after data has been deleted from it. Typically, you use Storage VMotion to move a VM location to another storage device; however, you can also leave the VM on its current storage device when performing a disk conversion. SVMotion can be invaluable when performing data storage maintenance as running virtual machines can be easily moved to other storage devices.

Some under-the-covers enhancements make the whole migration process much more efficient. Instead of using a snapshot when copying the disk to its new location and then committing it when the operation is complete, SVMotion now uses a new changed block tracking feature to keep track of blocks that changed after the move process started and then copies them after it completes.

Changed block tracking

Changed block tracking (CBT) is a significant new data storage feature that's especially important for backup, replication and other data protection applications. vSphere's VMkernel can now track which disk blocks of a virtual machine (VM) have changed from a particular time. By tapping the VMware vStorage APIs for data protection, applications can get the information from VMkernel rather than figuring it out on their own. CBT also enables near-real-time continuous data protection (CDP) when replicating VM disk files. CBT can also speed up incremental backups because backup apps can easily find out which changed blocks need to be backed up. Restoring data is much easier, too, with CBT because backup apps will know exactly what blocks need to be put back on the virtual disk for the restore point selected.

CBT is disabled by default because there's a slight performance overhead associated with it. It can be enabled only on the VMs that require it by adding a configuration parameter to the VM; backup applications that support changed block tracking can also enable it on VMs. Once enabled, CBT stores information about changed blocks in a special --ctk.vmdk file that's created in each VM's home directory. To do this, CBT uses changeIDs that are unique identifiers for the state of a virtual disk at a particular point in time. New changeIDs are created anytime a snapshot of a VM is created by a backup application. Using the changeID, a backup application will know which blocks have changed since the last backup. CBT is only supported on VMs that have virtual machine hardware Version 7 (which is new to vSphere), so older VMs will need to have their virtual hardware upgraded to use CBT.


This was first published in January 2010

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: