kentoh - Fotolia

Q
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Are vSphere Virtual Volumes necessary with an EVO:RAIL appliance?

Taneja Group's Tom Fenton explains how VVOLs work, and the storage differences between VVOLs and VSAN.

EVO:RAIL is a pre-configured hyper-converged appliance that uses VMware's software stack running on hardware from a VMware partner. The software stack includes VMware Virtual SAN (VSAN) for virtual machine (VM) storage. So, the short answer is no, you do not need vSphere Virtual Volumes (VVOLs) for storage on an EVO:RAIL appliance.

VSAN and Virtual Volumes are both VM-centric in that they allow virtual machines to consume storage. With either option, LUNs and volumes no longer need attributes such as performance and protection levels assigned to them, or VMs assigned to a LUN or volume to use these attributes. Both options allow the capabilities of the underlying storage to be surfaced up directly to vSphere. The VMs can then have storage provisioned for them based on these capabilities rather than indirectly through a LUN or volume. To do this, a policy is created in vSphere based on the desired attributes of the storage. This is known as Storage Policy Based Management (SPBM). By doing this, a VM can have the exact type of storage it requires. For example, an Oracle database may need highly performing storage with a high level of protection, whereas a dev/test VM may need only a moderate amount of performance without any protection.

When using SPBM with vSphere Virtual Volumes and storing the VMs on VSAN, the desired features are carved out of a storage pool and assigned to the VM when it is instantiated.

When using SPBM with vSphere Virtual Volumes and storing the VMs on VSAN, the desired features are carved out of a storage pool and assigned to the VM when it is instantiated.

Although VSAN and vSphere VVOLs both provide VM-centric storage, they have major differences. VSAN is a storage system that uses disks directly attached to the server, while VVOLs use storage arrays that are indirectly attached. VSAN has a set number of capabilities that a storage policy can be built from, including the amount of protection and performance. The capability for policies based on VVOLs depends on what the attached storage array provides. Some VVOLs-enabled storage will have a copious amount of capabilities, while others will have a limited amount from which to create policies.

VVOLS and VSAN

EVO:RAIL was designed to operate as a hyper-converged system where the hypervisor and the storage are contained on the same system and use VSAN to provide storage to the system. VSphere Virtual Volumes were designed for systems with attached storage.

Next Steps

The difference between VM-aware storage and VVOLs

VMware's vSphere VVOLs promise admins a better grip on VM data stores

The impact of Virtual Volumes on storage products

VMware's new feature for VVOLs: protocol endpoints

This was last published in April 2015

Dig Deeper on Hyper-Converged Infrastructure Management

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

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

Please create a username to comment.

How would you describe your experience with vSphere Virtual Volumes?
Cancel

-ADS BY GOOGLE

SearchDataCenter

SearchCloudStorage

SearchStorage

SearchNetworking

SearchVMware

Close