vCenter Tag based VM placement
Introduction
The idea behind tag based placement is quite simple. It assists administrators to keep VMs respectively VMDKs on desired datastores, based on tags. For example, a VM is defined to be located in datacenter 1 (DC1). With tag based placement you assign tag “Storage DC1” to all datastores in DC1 and configure a policy that is assigned to VMs in DC1. All wizards in vCenter take these policy into account.
Necessary components:
- Tag-category,
- Tags for datastores,
- Storage Policy Bases Management (SPBM) policy for tag based management.
Requirements:
- Datastores used for placement must be tagged. It is also possible to use datastores, not tagged with a specific tag. Either way, some datastores must be tagged.
- Each VM/VMDK that should be placed with policy, needs to assign a policy.
Basic setup in H5 Client
For this post I used current 6.7 U3 version of vCenter. As an example I demonstrate the setup for a two datacenter environment (DC1, DC2).
- First, create a tag-category. To do so go to Menu –> Tags & Custom Attributes –> CATEGORIES and press NEW
In this example I only use this category for datastores. - Then create a tag for each placement option. In this example I create a tag for each datacenter (“Storage DC1” and “Storage DC2”). Switch to TAGS and press NEW.
Select the right tag-category. - Now assign your tags to your datastores. You can do this by right-click a (or more) datastore(s).
And select tag.
Assign your tags to all datastores that should be used for placement. - Create Storage Policy Based Management (SPBM) policies. In this example a policy for each DC. These policies will be assigned to your VMs respectively VMDKs. Go to Menu –> Policies and Profiles –> VM Storage Policies. And press Create VM Storage Policy.
Go through the wizard:
Fill in Name and Description
Select options in policy. If you want to use this policy just for placement, select the option Enable tag based placement rules.
Select your tag-category and decide if you want the policy to include or exclude your tagged datastores. In this example I want to include tagged datastores.
And select appropriate tag.
Nice feature in wizard is the ability to view compatible and incompatible datastores to this policy.
During administration
There are at least two tasks, you are asked by wizard where to place a VM. These are: VM creation and storage vMotion.
VM Creation
A VM that gets created does not have any policies applied. Therefore you will see all datastores compatible.
Here you can select VM Storage Policy of choice and you will see compatible datastores for this policy.
When you select a compatible datastore, check compatibility is marked green. When datastore is not compatible you see a warning. This warning does not prevent you from VM creation!
Storage vMotion
For Storage vMotion it is very similar. There could already be a policy applied. During wizard you can change applied policy just like at VM creation. The difference is that you can also change policy per VMDK here. Click Configure per disk and select Browser at Configuration File or VMDK you want to migrate.
And choose policy in selection windows.
Applied another policy (without migration)
To apply another policy to a/more VM(s), go to VM –> Configure –> Policies.
Apply another policy per whole VM or for each VMDK separately.
When you apply a policy, location of VM is not compliant to, Compliance Status changes to Noncompliant. Migration to a compatible datastore would solve this status.
Change policy
When you change an existing policy, that is already applied to VMs, you will get a Compliance Status of Out of Date. Just Check compliance in GUI or CLI (later in this post) and you get a current state.
Useful PowerCLI commands
Show tagged datastores (category: CategoryName)
Get-Datastore | Get-TagAssignment -Category CategoryName
Show un-tagged datastores (category: CategoryName)
$TaggedDSs = @((Get-Datastore | Get-TagAssignment -Category CategoryName).Entity) ForEach ($DS in Get-Datastore) {if ($DS -notin $TaggedDSs) {$DS.name}}
Show all VMs without an applied storage policy
Get-VM | Get-SpbmEntityConfiguration | where {$_.StoragePolicy -eq $null}
Check policy compliance for a specific VM (VMname)
Get-SpbmEntityConfiguration -VM VMname -CheckComplianceNow
Show all VMs not compliant to applied storage policy. This command only shows VMs when location of configuration files are not compliant.
Get-SpbmEntityConfiguration -VMsOnly | where {$_.ComplianceStatus -ne "compliant"}
This command shows an entry for each VMDK or VM where location does not meet policy.
Get-SpbmEntityConfiguration | where {$_.ComplianceStatus -ne "compliant" } | select @{N="entitiy"; E={get-vm -Id ($_.id).Split("/")[0]}}, Entity, StoragePolicy, ComplianceStatus, TimeOfCheck
Limitations
- As you can see in this post, it is not mandatory to place a VM on a compatible datastore. Just a warning is displayed.
- There is a pre-defined alarm in vCenter “VM storage compliance alarm”. For my understanding this alarm should fire, when a VM/VMDK is not compliant to storage policy. At least in relation to a placement policy I did not manage to trigger this alarm at all. Even VMware support did not solve the situation.
- I did also find no way to manage to get an alarm-icon in vCenter inventory when a VM is not compliant to placement policy. So all non-compliant VMs would could be seen at first glance in GUI. To find VMs in GUI not compliant you have to:
- Menu –> Policies and Profiles –> VM Storage Policies –> Select Policy –> VM Compliance
- Select VM –> Configure –> Policies
- Menu –> Policies and Profiles –> VM Storage Policies –> Select Policy –> VM Compliance
- Actually there is no connection between storage and host-placement. This means when you use tag based placement like in my example to place VMs in one of more datacenter, there is no automatism to run this VM on a host in the same datacenter. To do so you can write a script to migrate VMs or place them in corresponding DRS group on a regular schedule.
IMHO
This is a nice application of vCenter tags. It makes it more simple to keep VMs on desired datastores. But it is no complete solution for this problem, because there is no alarm for a VM running on a incompatible datastore and because the hosting ESXi server cannot be managed.
In my opinion the usage of storage policies can be cumbersome. If you use policies just for one task like placement, it is handy because you just need as much policies as you have groups of datastores. A huge limitation of storage policies is that there can just be on policy applied to a VM respectively VMDK. So when you need more options in a policy that does not fit for all VMs you need to create as much policies as you have distinguished options within policies. This can be overwhelming very fast.