WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Applying Custom Attributes beyond just Host & Virtual Machine Objects

03.09.2016 by William Lam // 5 Comments

I recently came to learn about a neat little tidbit from one of my readers, Ziad, regarding vSphere Custom Attributes. I had been a long time user of Custom Attributes when I was a customer and heavily used it in-conjunction with Automation. This is how many of our customers leveraged this capability, especially around provisioning and reporting use cases. Custom Attributes allows you to specify custom "keys" associated with either a Virtual Machine or an ESXi host object. Once these keys have been created, you can then assign object-specific metadata "values" to these objects. An example would be a Custom Attribute called "Application Owner" and for VM1 I can have a value of "Duncan Epping" and for VM2 I can have a value of "Alan Renouf".

Custom Attributes can be created using either the vSphere API or from the vSphere C# Client (currently not possible using the vSphere Web Client). The UI has already restricted Custom Attributes to either a Host, Virtual Machine or Global which means it applies to both objects as shown in the screenshot below. This has always been my understanding of how Custom Attributes work and has also been documented as such.

applying-custom-feilds-beyond-hosts-and-vms-0
Well, it turns out, this "restriction" was only a UI restriction. The actual Custom Attributes feature can actually be applied across variety of vSphere Objects and not just limited to Hosts and Virtual Machines when using the vSphere API. If we look at the Custom Attributes API which uses the customFieldsManager and specifically the AddCustomFieldDef() method which is used to create new custom fields. We can see that the moType property can accept any of the supported vSphere Objects such as the following:

  • ClusterComputeResource (Multi-ESXi host Cluster)
  • ComputeResource (Single ESXi host Cluster)
  • Datacenter
  • Datastore
  • DistributedVirtualSwitch
  • Folder
  • HostSystem
  • Network
  • ResourcePool
  • StoragePod (Datastore Cluster)
  • VirtualApp
  • VirtualMachine

I decided to quickly verify this by giving this a try in my lab and using PowerCLI (just one of the many options to the vSphere API) to exercise the Custom Attributes API against a Datacenter, Cluster, Datastore and Network object.

We start off by retrieving the CustomFieldsManager and then creating four new Custom Fields for each of the respective vSphere Objects that we want to associate with.

$customFieldMgr = Get-View ($global:DefaultVIServer.ExtensionData.Content.CustomFieldsManager)

# Custom Field Key names

$dcCFName = "DatacenterCF"
$clCFName = "ClusterCF"
$dsCFName = "DatastoreCF"
$netCFName = "NetworkCF"

# Create Custom Field Keys for Datacenter, Cluster, Datastore & Network objects

$customFieldMgr.AddCustomFieldDef($dcCFName,"Datacenter",$null,$null)
$customFieldMgr.AddCustomFieldDef($clCFName,"ClusterComputeResource",$null,$null)
$customFieldMgr.AddCustomFieldDef($dsCFName,"Datastore",$null,$null)
$customFieldMgr.AddCustomFieldDef($netCFName,"Network",$null,$null)

Next, we retrieve a Datacenter, Cluster, Datastore and Network object in our vSphere inventory and then call the setCustomValue() API which is used to set the value for a particular Custom Attribute that has been defined for that object.

# Set Custom Field for Datacenter, Cluster, Datastore & Network objects

$datacenterName = "Santa-Barbara"
$datacenterView = Get-View -ViewType Datacenter -Property Name -Filter @{"name"=$datacenterName}
$datacenterView.setCustomValue("$dcCFName","AB-123")

$clusterName = "Production"
$clusterView = Get-View -ViewType  ClusterComputeResource -Property Name -Filter @{"name"=$clusterName}
$clusterView.setCustomValue("$clCFName","BC-456")

$datastoreName = "datastore1"
$datastoreView = Get-View -ViewType Datastore -Property Name -Filter @{"name"=$datastoreName}
$datastoreView.setCustomValue("$dsCFName","CD-789")

$networkName = "VM Network"
$networkView = Get-View -ViewType Network -Property Name -Filter @{"name"=$networkName}
$networkView.setCustomValue("$netCFName","EF-012")

If we take a look at our vSphere Web/C# Client, we should see tasks being initiated on setting the custom value. So far, so good.

applying-custom-feilds-beyond-hosts-and-vms-1
Finally, it is time to retrieve these Custom Attributes to see if they were indeed properly set. We first need to build up a hash table of the key's name, so we can easily correlate the specific Custom Attribute name with the unique key ID. Next, we can then extract the Value property which extends CustomFieldStringValue and contains both the key which we can look up from our look up table and most importantly, the value which contains the data that we had set earlier.

# Retrieve Custom Field for Datacenter, Cluster, Datastore & Network objects

# Create Custom Field & Name lookup table
# Borrowed from my buddy Alan Renouf http://www.virtu-al.net/2009/05/29/powercli-on-steroids-custom-attributes/
$customKeyLookup = @{}
$customNameLookup = @{}
$customFieldMgr.Field | % {
$customKeyLookup.Add($_.Key, $_.Name)
$customNameLookup.Add($_.Name, $_.Key)
}

# Print the Custom Fields property for each vSphere Object

$datacenterView = Get-View -ViewType Datacenter -Property Name,Value -Filter @{"name"=$datacenterName}
Write-Host "`nDatacenter:" $datacenterName "has Custom Field:" $customKeyLookup[$datacenterView.Value[0].Key] "with value:" $datacenterView.Value[0].Value "`n"

$clusterView = Get-View -ViewType  ClusterComputeResource -Property Name,Value -Filter @{"name"=$clusterName}
Write-Host "`Cluster:" $clusterName "has Custom Field:" $customKeyLookup[$clusterView.Value[0].Key] "with value:" $clusterView.Value[0].Value "`n"

$datastoreView = Get-View -ViewType Datastore -Property Name,Value -Filter @{"name"=$datastoreName}
Write-Host "`Datastore:" $datastoreName "has Custom Field:" $customKeyLookup[$datastoreView.Value[0].Key] "with value:" $datastoreView.Value[0].Value "`n"

$networkView = Get-View -ViewType Network -Property Name,Value -Filter @{"name"=$networkName}
Write-Host "`Network:" $networkName "has Custom Field:" $customKeyLookup[$networkView.Value[0].Key] "with value:" $networkView.Value[0].Value "`n"

Here is a screenshot of running the above PowerCLI code and we can see the values match up with what we had set earlier. This is pretty awesome if you ask me!

applying-custom-feilds-beyond-hosts-and-vms-2
Some of you might be thinking, if Custom Attributes can be applied across different vSphere Objects, then why should I use vSphere Tags? Well, there are definitely some differences between the two today and I highly recommend you give this article a read first before continuing further. Although Custom Attributes may provide similiar behaviors to vSphere Tags, there is a lot of limitations that come with Custom Attributes. I do believe vSphere Tags is the future and when we bring vSphere Tags to parity with some of the use cases that Custom Attributes can only cover today only, it will be an even more powerful feature.

There are several major benefits to vSphere Tags over Custom Attributes. One they are multi-vCenter Server aware when joined to the same SSO Domain, which means existing Tags/Tag Categories are automatically made available versus Custom Attributes which are bounded by a single vCenter Server. vSphere Tags is also deeply integrated with VM Storage Policy and Content Library for provisioning which is lacking with Custom Attributes and require custom Automation to leverage its metadata. A single vSphere Tag can support one or more groupings to a given vSphere Object, where as Custom Attribute must be tied to a single object. Lastly, being able to globally search across various tagged vSphere Objects is trivial with vSphere Tags. For Custom Attributes, you would need to first identity the object which means you must search through all objects unless you know the one you are looking for first and then iterate through the list of Custom Attributes looking for the specific key and then finally the value. There is definitely still room for improving vSphere Tags, but I think it is definitely the more superior metadata system that customers should be looking at going forward.

One final note which I thought was interesting is that PowerCLI also provides a few cmdlets for managing Custom Attributes and it looks like they did in fact support different vSphere Object types as documented here. The only issue is that it does not cover all vSphere Objects that is possible and if you still may want to consider calling into the vSphere API from PowerCLI and by-passing the default cmdlets.

Categories // Automation, vSphere Tags // custom attributes, metadata, PowerCLI, tag, tagging

Custom Attributes != vSphere Tags

01.13.2015 by William Lam // 21 Comments

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-custom-attributes-are-not-equal-to-vsphere-tags-1
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.

vsphere-custom-attributes-are-not-equal-to-vsphere-tags-0
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.

Categories // vSphere Tags // custom attributes, metadata, tagging

vSphere Web Client Plugin for Custom Attributes

02.07.2014 by William Lam // 19 Comments

I just learned about a very cool vSphere Web Client Plugin that was developed by a fellow vExpert, Patrick Haefner who shared this during the South Germany VMUG back in February of last year. The custom vSphere Web Client Plugin allows administrators to view Custom Attributes in the vSphere Web Client which is currently not available today. The Custom Attributes vSphere Web Client is hosted on the VMUG site and you will need to register to access the download page found here.

Disclaimer: This plugin is not officially supported by VMware, please use at your own risk.

To install the Custom Attributes plugin, you just need to extract the contents of the zip file and you will should see a directory called haif-customfields-ui. You will need to copy this directory to your vCenter Server which is running the vSphere Web Client. This plugin should work on both vSphere 5.1 and 5.5.

For Windows vCenter Server:

  1. Stop the vSphere Web Client service
  2. Copy haif-customfields-ui to C:\Program Files\VMware\Infrastructure\vSphereWebClient\plugin-packages
  3. Start the vSphere Web Client service

For VCSA (vCenter Server Appliance)

  1. Stop the vSphere Web Client service by running /etc/init.d/vsphere-client stop
  2. Copy haif-customfields-ui to /usr/lib/vmware-vsphere-client/plugin-packages
  3. Start the vSphere Web Client service by running /etc/init.d/vsphere-client start

Once the vSphere Web Client has been started, you can now login and for Virtual Machines or ESXi hosts which have Custom Attributes, you should now see a new portlet displaying the Custom Attributes as seen in the screenshot below.

I think this is a really cool plugin and shows how extensible the vSphere Web Client is by leveraging the vSphere Web Client SDK. With a bit of imagination, you can pretty much build anything! Though today Patrick's plugin only allows you to view the Custom Attributes, perhaps if there is enough requests, he may add the ability to modify Custom Attributes. Awesome work Patrick and thanks for sharing it with the community!

Big thanks to Ruediger M. who works as a VMware SE in Germany for sharing this awesome information. This is definitely a plugin I will be installing in my environments 🙂

Categories // vSphere Web Client Tags // custom attributes, plugin, tagging, vSphere, vsphere web client

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...