The ability to tag and note virtual objects has served me well in the past, but there was always this feeling that tags were just for human eyes. Scripts could take advantage of them, and Security Tags are quite helpful for NSX related solutions, but more could certainly be done.
[symple_box color=”red” fade_in=”false” float=”center” text_align=”left” width=””]… and apparently this is just wishful thinking. Numerous VMware employees have stated that this feature did not make the release. I’ve left the content below and hope to see included in a later release.[/symple_box]
The new Policies and Profiles section, coupled with the new Virtual Data Center construct and being able to tag just about anything, gives administrators much more control over a dynamic data center environment. I’ve been quite impressed with this feature and have set it up for my Spongy friends in the Wahl Network v6 lab.
The end goal is to wrap policy around a workload, toss it at the SDDC (or in this case, a Virtual Data Center), and let the policy enforcement do the rest.
Getting Started
In this post, I’m going to walk through the steps necessary to apply placement and storage policies onto my production MS-DOS server named SquarePants. As you can see below, he’s happily compliant with a number of policies.
The Policies and Profiles section is found in the home screen of the vSphere Web Client. Hard to miss it.
Once you navigate to the Policies and Profiles section, you’ll see a handful of items. We’re only interested in two of them:
- VM Storage Policies
- VM Placement Policies
We’re going to visit the VM Placement Policies first for various reasons I’ll cover in a bit. The other options are old hat.
Let’s dig deeper.
Placement Policies
By default, VMware populates the policies section with a few common sense items for licensing, ownership, lifecycle management, and so on. Each policy contains one or more tags that relate to that policy. For example, Lifecycle contains the production, test, stage, and development tags.
We’re going to add some new tags to the Quality of Service policy using real-world values that all businesses will cherish. These are:
- Hater of Sponges
- Sponge Friendly
Let’s not stop there! We’ll also create a brand new policy called Storage that will be used to tag datastores with their readiness to run VMs. Note that you have two choices here:
- Allow objects to receive just one tag per policy. This is good for mutually exclusive items, such as the CPU type.
- Allow multiple tags per object, which might be handy for a list of features or tiers such as “this cluster can host Gold and Silver VMs.”
We’re going to use one policy tag per object for the Storage policy.
Let’s create two simple tags: VMs Allowed and VMs NOT Allowed. Again, I’m sure all enterprise environments will flock to this silly use case. But it’s fun!
There, now we’re done with building policies and tags. Let’s use them on something!
Tagging a Cluster
We now want to tag a cluster so that we know what it can provide. It’s a bit like asking a car salesperson what options are available with your car. Power locks, air conditioning, cup holders?
Navigate to a cluster object and assign tags that represent the features available on your cluster. Below is a sample list of tags available in my lab environment.
Once tags are applied, we can see that the Lab v6 cluster offers workloads the following features: AMD CPUs, a place to Test VMs, and Sponge Friendly QoS.
Sadly, no cup holders. 🙁
Let’s do a similar exercise for a datastore.
Tagging Storage
Much like tagging a cluster, we can also tag storage.
I personally like to mount a datastore named NAS1-Files for files and ISOs but leave it writeable to easily add more stuff later. Let’s tag the NAS1-Files datastore with the VMs NOT Allowed policy so that no one can try to run VMs on this thing. It’s as simple as clicking the assign link and picking the right tag.
We’re also going to tag my other storage, NAS2-Lab, with the VMs Allowed tag.
Now that storage has been tagged, return to the Policies and Profiles and select VM Storage Policies.
Storage Policies
Next, let’s create the Fun Storage Policy … great name, right? But wait, there’s a step missing!
We need to enable the use of storage policies, first. This means:
- Click the little policy with a green checkmark button
- Select your vCenter environment
- Choose a cluster
- Click Enable
Now that the cluster is enabled and licensed, it’s time to build the Fun Storage Policy. This policy has one goal: it allows VMs to only live on storage with the VMs Allowed tag created earlier. Thus, the only rule we need to make uses the VMs Allowed tag as shown below.
Once the rule is created, the storage compatibility section reveals that one datastore is compatible: the NAS2-Lab datastore marked with the VMs Allowed tag.
Complete the wizard to finish the Fun Storage Policy.
VM Compliance
The policies don’t do much unless workloads are configured to use them. Let’s make sure that my critical MS-DOS VM has some policies assigned!
- Select the VM and choose the Actions menu
- Navigate to VM Policies
- Choose Edit Policies for placement and storage policies
- The Edit VM Storage Policies section is sort of redundant, so we’re just going to click on Item #3 (Edit Policies) instead.
Here we can set the storage policies for this VM. If your choices are grayed out, you didn’t enable storage policies. Choose the Fun Storage Policy.
Next, add a policy for the various Placement tags. Let’s make AMD a Preference, while QoS and Lifecycle will be Requirements. Preferences are soft rules, while Requirements are hard rules.
A quick check reveals that my cluster provides all of the necessary tags to meet my policy requirements.
Virtual Data Center View
Let’s step back a bit and see how this looks from the perspective of a Virtual Data Center. The policies written at the cluster level have bubbled up to the VDC. We can drill down into the three features – CPU, Lifecycle, and QoS – to see what’s been tagged and how the VMs are affected.
Seeing everything green and happy is no fun. Let’s cause some chaos!
Remediation
I’ll secretly edit the cluster and change the CPU tag to Intel and the QoS tag to Hater of Sponges, making the VM no longer compliant. Mwhaha!
Notice that CPU Architecture just results in a warning because I used a Preference, while QoS is an alert because that field is a Requirement. Clicking Remediate will force vSphere to try and find a new home for the VM. Alternatively, we could just fix it ourselves by assessing the issue and moving the VM elsewhere.
Thoughts
There are many more use cases for this – especially the licensing policy for those using SQL or Oracle, as an example. I really dig the idea of being able to tag virtual data centers, clusters, and workloads with any design requirements to fulfill functional needs. Especially when I think of all the cruddy DRS rules and groups that I used to leverage to do similar, if not more brute force, activities.
In future builds, VMware has hinted at making a VDC (Virtual Data Center) span multiple vCenter Servers. It would truly become an aggregation layer for the Abstract, Pool, Automate mantra. Resources would then be logically carved up by vRealize Automation or other such cloud management platforms.
