WilliamLam.com

A common question that I see frequently asked by customers is whether Custom Attributes in vCenter Server can be completely replaced by vSphere Tags? Both Custom Attributes and vSphere Tags provide metadata capabilities, but there are some underlying differences between the two and depending on how you use Custom Attributes today, you may or may not be able to completely migrate over to using vSphere Tags, at least in the short term.

UPDATE (11/16/16): vSphere 6.5 now allows you to fully view and manage Custom Attributes directly from the vSphere Web Client.

Custom Attributes allows you to specify custom "keys" associated with either a Virtual Machine or an ESXi host object using the vSphere C# Client. which are the only supported objects When using the vSphere API, you can apply Custom Attributes it across variety of vSphere Objects and for more details, please have a look at this post here. Once enabled for either a VM or an ESXi host, you will be able to assign an object-specific metadata "value" to these objects. An example would be a Custom Attribute called "Application Owner" and for VM1 I have a value of "Duncan Epping" and for VM2 I have a value of "Alan Renouf".

vSphere Tags also provides a metadata capability, but it goes beyond just VMs and ESXi host. vSphere Tags can be applied to all objects within the vSphere Inventory. A major distinction between Custom Attributes and vSphere Tags which will help answer our initial question is that vSphere Tags can not be used to store object-specific metadata, it is used for categorizing or logically organizing various objects together. An example would be a Tag called "Production" which can then be assigned to VM1 and VM2 for organizational purposes but you would not be able to assign a specific value for each of the VMs.

This distinction of not being able to assign object-specific metadata is the key difference between vSphere Tags and Custom Attributes. If you currently rely on this capability of Custom Attributes, you will not be able to completely migrate over to using vSphere Tags. A good way to think about vSphere Tags today is that they are similar to vSphere Folders but much more dynamic and search across all vSphere Objects. The lack of object-specific metadata for vSphere Tags is something that VMware Engineering is aware of today and hopefully they will be able to enhance in the future to support the Custom Attributes use case, so that vSphere Tags can be used exclusively.

In fact, I also hope to see vSphere Tags get enhanced so that permissions can also be applied onto Tags which would then propagate to the underlying associated vSphere Objects. I know this is another common request from customers that have looked at using vSphere Tags. I would like to also see a proper API exposed for Tags so that they can be managed and accessed programmatically, which can be quite handy for CMDB or provisioning systems. Today, there are no vSphere APIs for Tags, but you can manage them using PowerCLI Tagging cmdlet. Searchability is also another area that vSphere Tags can get further enhancements on. Today you can only search on objects by Tag name, but in the future I hope to see support for more complex queries which include searching through the values of the Tags assigned.

In summary, Custom Attributes are not going away anytime soon, at least until their capabilities are on-par with vSphere Tags. You will be able to continue accessing Custom Attributes which is available today in the vSphere C# Client or using the vSphere API. Custom Attributes are currently not visible in the vSphere Web Client, but you can use this custom vSphere Web Client plugin which makes the Custom Attributes available in the vSphere Web Client. Going forward, the future will be vSphere Tags, but in the mean time you may want to use both sets of metadata capabilities depending on your use case.