Yellow Bricks

by Duncan Epping

policy

vSAN Storage Rules policy capability allows to set dedupe per VM?

· ·

There was a question posted on the VMware Community Forums, and as this is something I have been asked regularly, I figured I would do a quick blog post about it. Although I have covered this before, it doesn’t hurt to repeat, as it appears to be somewhat confusing for people. When you create a VM Storage Policy, starting with vSAN 7.0 U2 you have the ability to specify if a VM needs to be Encrypted, have Dedupe and Compression enabled, have Compression-Only enabled, and/or needs to be stored on all-flash vSAN or Hybrid. Never noticed it? Look at the screenshot below.

In the screenshot, you see that you have the ability to specify which data service needs to be enabled. I guess this is where the confusion comes into play, as this functionality is not about enabling the data service for the VM to which you assign the policy. This is about which data service needs to be enabled on the datastore to which the VM can be provisioned. Huh, what? Okay, let’s explain.

If you are using vSAN as your storage platform, and you are sharing vSAN Datastores between clusters leveraging the HCI Mesh feature, then you could find yourself in a situation where some clusters are hybrid and some are all-flash. Some may have data services enabled like Encryption or Deduplication, some may not. In that scenario you want to be able to specify which features need to be enabled for the datastore the VM is provisioned to. So what this “storage rules” feature does is that it ensure that the datastore which is shown as “compatible” actually has the specified capabilities enabled! In other words, if you tick “data-at-rest encryption” in a policy and assign the policy to a VM, then only the datastores which have “data-at-rest encryption” enabled will be shown as compatible with your VM!

So again, “storage rules” apply to the data services that should be enabled on the vSAN Datastore, and do not enable data services on a per VM/VMDK basis.

<Update for vSAN 8.0 ESA>

With vSAN 8.0 ESA the above has changed. With vSAN 8.0 ESA you can set compression per VM, and you actually do that using the policy storage rules. I discussed this in this blog post.

vSphere 5.0: Profile-Driven Storage, what is it good for?

· ·

By now most of you heard about this new feature called Profile-Driven Storage that will be introduced with vSphere 5.0, but what is it good for? Some of you, depending on the size of the environment, currently have a nice long operational procedure to deploy virtual machines. The procedure usually contains gathering information about the requirements of the virtual machine’s disks, finding the right datastore to meet these requirements, deploy the virtual machine and occasionally check if the virtual machine’s disks are still placed correctly. This is what Profile-Driven Storage aims to solve.

Profile-Driven Storage, in the vCenter UI referred to as VM Storage Profiles, decrease the amount of administration required to properly deploy virtual machines by allowing for the creation of Profiles. These profiles typically list the requirements of storage and can be linked to a virtual machine. I know it all sounds a bit vague, let me visualize that:

In this scenario a virtual machine requires “Gold Storage”, now lets just assume for now that that means RAID-10 and Replicated. By linking the profile to this virtual machine it is possible to validate if the virtual machine is actually located on the right tier of storage. Now this profile can of course be linked to a virtual machine / virtual disk after it has been provisioned, but even more importantly it can be used during the provisioning of the virtual machine to ensure the user picks a datastore (cluster) which is compatible with the requirements! Just check the following screenshot of what that would look like:

Now you might wonder where this storage tier comes from, this is a VM Storage Profile containing storage capabilities provided by:

  • VASA aka vSphere Storage APIs – Storage Awareness
  • User defined capabilities

User defined capabilities are fairly simple to explain, the profile you create (gold / silver / bronze) will be linked to a User Defined “tag” you define on a datastore. For instance you could tag a datastore as “RAID-10”. When would you do this? Well typically when your storage vendor doesn’t offer a Storage Provider for VASA (yet). That takes us to the second method of selecting storage capabilities for your VM Storage Profile, VASA. VASA is a new “API” which enables you to see the characteristics of a datastore through vCenter. With characteristics I am referring to things like: raid level, de-duplication, replication etc. You know what, my a step-by-step guide makes it clear:

  • Go to VM Storage Profiles
  • Create a VM Storage Profile
  • Provide a Name
  • Select the correct Capabilities
  • Finish the creation
  • Create a new VM and select the correct VM Storage Profile, note that only 1 datastore is compatible
  • After creation you can easily check if it is compliant or not by going to the VMs summary tab

A couple of simple initial steps as you can clearly see, but a huge help when provisioning virtual machines and when validating storage / vm requirements!