One of the coolest feature in my opinion is Tagging in the new vSphere Web Client. Unlike Custom Attributes which was limited to an ESXi host and Virtual Machine object, the new Tagging capability allows you to create custom labels and metadata on ANY vSphere inventory object. In addition, you can have multiple tags per object and you can search based on tags to help you quickly find what you are looking and making this feature even more powerful. Just like with anything new, it takes time to get used to. To help you use the new Tagging feature, there is a built in Custom Attributes to Tags migration tool in the vSphere Web Client as Tagging will be the future going forward.
This tool walks you through the migration process and allows you to select all or a subset of the Custom Attributes you currently have in your environment to migrate over to Tags. Migrated Custom Attributes are not removed or modified after the migration to tags, so you will still be able to consume Custom Attributes in the old vSphere C# Client or programmatically using the vSphere API and CLIs.
A caveat that users have found after migrating a set of Custom Attributes is that they are no longer available for migration again which makes sense as you do not want a user to accidentally migrate the same Custom Attribute again. As asterik (*) is shown for for Custom Attributes that have been migrated and the tool prevents you from proceeding as show in the screenshot below.
But what if you want to re-run the migration tool or start all over again? Well it turns out you can easily restart the process again without too much hassle. After a Custom Attribute has gone through a migration, the information is stored in a binary file located on the vSphere Web Client Server. I actually accidentally stumbled upon this file while working on a completely random project:
1
%programdata%VMwarevSphere Web ClientSerenityDBserenityALLtagscustomattributesmigrated
The migrated file is updated each time a Custom Attribute has gone through a migration. To be able to reset or restart the migration process for Custom Attributes that have already been migrated, you just need to delete the migrated file and then log back into the vSphere Web Client.
An important thing to note, existing Tags that have already been migrated over will not be automatically removed. This means if you migrate the Custom Attributes again, they will automatically be appended with incremental number and you will have duplicate Tags. This can easily be fixed by removing the old Tags before going through the migration process again.
Hopefully now that you can easily restart the Custom Attributes to Tags migration process, you can experiment and see what the results will be after a conversion and make the necessary changes without being limited on how many times you can re-run the migration.
Get notification of new blog postings and more by following lamw on Twitter: @lamw
This tool walks you through the migration process and allows you to select all or a subset of the Custom Attributes you currently have in your environment to migrate over to Tags. Migrated Custom Attributes are not removed or modified after the migration to tags, so you will still be able to consume Custom Attributes in the old vSphere C# Client or programmatically using the vSphere API and CLIs.
But what if you want to re-run the migration tool or start all over again? Well it turns out you can easily restart the process again without too much hassle. After a Custom Attribute has gone through a migration, the information is stored in a binary file located on the vSphere Web Client Server. I actually accidentally stumbled upon this file while working on a completely random project:
Hopefully now that you can easily restart the Custom Attributes to Tags migration process, you can experiment and see what the results will be after a conversion and make the necessary changes without being limited on how many times you can re-run the migration.
