Home > Blogs > VMware vSphere Blog

vSphere Inventory Searching and Tagging

With the release of vSphere 5.1, many new features were added and I really like some of the new search capabilities which can be great timesavers when administering a vSphere environment.

You have always been able to search the inventory but now we have the ability to see our results categorized with inventory lists found in the vSphere Web Client which help quickly locate what your are seeking. You can run really specific searches across multiple object types and conditions and then save them for future use so you don’t have to repeat the selection process, all of this can be accessed from anywhere in the vSphere Web Client.

Another new feature that further enhances the search capabilities is called tags. Tags are the ability to create custom labels and or metdata and apply to any object with the vCenter inventory for say organization and or grouping. Objects can have multiple tags so if you have ever come across the limitation with folders where an inventory object can only exist in one folder at a time, tags is your answer. The other great usecase about tags is they are fully searchable so you can now provide granular searches on the attached labels and metadata to further reduce time when retrieving information.

To show these new search capabilities I have added the following video to demonstrate these great time saving features vSphere 5.1.

11 thoughts on “vSphere Inventory Searching and Tagging

  1. Paul Poppleton

    As I understand it tags actually replaces custom fields in this version which may severely impact some customers. We make fairly decent use of custom fields today. Nothing of a critical nature but still the move to 5.1 will require some modifications to occur in our environment since we update those fields as part of some of our processes which are automated. After upgrading I noticed some of my scripts failing and discovered that custom fields were still there but can no longer be up updated. I am happy to see VMware make this change as I have always thought custom fields were poorly implemented but it would have been nice to have 5.1 make a more friendly transition by keeping them read/write for this version.

    There is what appears to be a nice wizard for converting them to tags. I am hopeful that the api’s for the custom fields might auto magically work once I convert them or that they are very similar so making the coding changes is minimal but I haven’t gotten that far yet.

    5.1 adds some really great new features but as a customer I really feel this was a much larger release than what we see in a typical dot release. 5.5 would have prepared me better for the SSO nightmare and tags as I am wary when I see a jump like that. I feel like there are some other fairly significant changes like the new web client (which it seems like some of the new features such as creating a new vm that uses the latest virtual hardware require you to use it), changes to the vShield products, modifications in the distributed virtual switches, and a grip of other things I can’t think of off the top of my head.

    The reality is mostly no harm done as we don’t just plop this stuff into our production environments but I feel it was a missed opportunity in ways for VMware .

    1. Justin KingJustin King Post author

      thanks fro the feedback, you can still use custom attributes, they can be viewed in the vSphere web client as read only and you can still edit/add with the desktop client.

  2. Ty Morton

    Are tags going to become a first class citizen at some point? I can see value in using tags to perform other actions such as power on / restart policy. It would also be nice to tagg all Dev VM’s to be shutdown on a DR event that can be handled by SRM. There might need to be some sort of validation around using tags to perform actions due to the nature of multiple tags etc. I still think it is a great way to start to interact with large quantities of VM’s.


  3. Andrew

    If I understand this correctly, tags are simply “labels” that can be assigned to objects in the inventory? So is there no real concept of a field anymore? For example, we have a custom field called “Owner”, which we then populate with the name of the person who is responsible for a particular VM. I take it this would no longer really be possible, we would have to have a tag for every owner and just assign that tag to each VM that person is responsible for?
    Also, we use Veeam for backups and have Veeam automatically fill in a custom field when a backup is successful, so a user can quickly see the last time a successful backup of that VM was taken. Can I assume this has also gone away?

    1. Mark

      I recently upgraded and find myself in the same situation Andrew. We also use attributes for things like owner, date created, etc. To think I have to create a tag for every date is clearly not feasible. Did you find away around this? I have been searching for a good document on properly implementing tags and have yet to find such a guide.

      1. Matt

        Did you ever find a way around this? I’ve found you can still set a custom attribute called something like “Date” and then just use set-annotation -customattribute Date -value “00/00/0000 00:00:0000” however I’d really like to do this in tags without having to create a tag for every single timestamp. There is no way to sort or view annotations in the web client as I believe they will soon be depreciated so I’m hoping there is a solution soon for creating tags on the fly for specific value types like dates, etc.

  4. Pingback: Welcome to vSphere-land! » vSphere 5.1 Link-O-Rama

  5. Pingback: How To Restart The Custom Attributes To Tags Migration Process | VMware vSphere Blog - VMware Blogs

  6. Pingback: Instalar VMware vCenter Server – Parte III | G_One

  7. Jennifer Wagner

    I am auditing our VMware folders for backups, to verify we are backing up the folders. It would be extremely helpful to have folder tagging, to allow me to indicate that folder foo is backed up by job foo_backup. My manual process is to pull apart my job definitions, pull out the indicated folders, query VMware for all the VMware folders. Spend the next few hours in Excel. I would much prefer to query VMware for folder objects without a backup job tag. Granted a real audit should still be done, but a report of folders with these tags would shave hours of combining the two data streams.

    Folder are objects too! (Just Saying….)

    Jenn Wagner


Leave a Reply

Your email address will not be published. Required fields are marked *