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. So far, so good.įinally, it is time to retrieve these Custom Attributes to see if they were indeed properly set. $networkView = Get-View -ViewType Network -Property Name -Filter we take a look at our vSphere Web/C# Client, we should see tasks being initiated on setting the custom value.
![networkview no longer supported networkview no longer supported](https://help.fullstory.com/hc/article_attachments/360045710273/direct_1554999506100-1554999506100.png)
$datastoreView = Get-View -ViewType Datastore -Property Name -Filter = "VM Network" $clusterView = Get-View -ViewType ClusterComputeResource -Property Name -Filter = "datastore1" $datacenterView = Get-View -ViewType Datacenter -Property Name -Filter = "Production"
![networkview no longer supported networkview no longer supported](https://i.ytimg.com/vi/c0yFLl1Z5yY/maxresdefault.jpg)
# Set Custom Field for Datacenter, Cluster, Datastore & Network objects 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. $customFieldMgr.AddCustomFieldDef($netCFName,"Network",$null,$null) $customFieldMgr.AddCustomFieldDef($dsCFName,"Datastore",$null,$null) $customFieldMgr.AddCustomFieldDef($clCFName,"ClusterComputeResource",$null,$null) $customFieldMgr.AddCustomFieldDef($dcCFName,"Datacenter",$null,$null) # Create Custom Field Keys for Datacenter, Cluster, Datastore & Network objects 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. 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. ComputeResource (Single ESXi host Cluster).We can see that the moType property can accept any of the supported vSphere Objects such as the following: 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. Well, it turns out, this "restriction" was only a UI restriction.
![networkview no longer supported networkview no longer supported](https://slotabc.weebly.com/uploads/1/2/5/0/125027896/291595991.png)
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. 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".Ĭustom Attributes can be created using either the vSphere API or from the vSphere C# Client (currently not possible using the vSphere Web Client). This is how many of our customers leveraged this capability, especially around provisioning and reporting use cases. 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.