Our environment uses multiple CustomAttribute annotations on VMs. I've noticed that when I use Get-TagAssignment on VMs in our vCenter, the Entity object, which should be just a VM (VirtualMachineImpl) object, has a Name which includes all/most of the CustomAttribute annotation names. This occurs regardless of whether I'm doing anything with regard to CustomAttributes or not. I've tested this on multiple vCenters and multiple PowerCLI instances (all 6.0R3) on different computers with similar behavior. I tried searching and I couldn't find any reference to a bug anywhere.
Also odd is that some of the VMs seem to have the VM name listed first, then the various CustomAttribute names. Other VMs, however, seem to list the CustomAttribute names first and the VM name at the end. No apparent reason for difference.
This feels like a bug, but I want to confirm whether this is something unusual about my environment or whether others are able to reproduce this.
Steps to reproduce (assuming standard modules are loaded):
> Connect-VIServer [vcenterServer]
> $vmTags = Get-VM | Get-TagAssignment
Will list Entity as '[CustomField1Name] [CustomField2Name] ... [CustomFieldnName] [VMName]'
Interestingly, listing $vmTags.Entity.Name will actually only return the VM Names themselves (without CustomAttribute names). So it's still usable for name matching.
If this is something specific to my environment, does anyone have any thoughts on what might be causing it?
Nice to know I wasn't crazy. I was seeing the same ting. But just to be sure.Is this a powercli 6.0R3 bug? I just wanted to make sure it wasn't indicative of something wrong in my vcenter db.
Also is it just a display bug or is it causing tag related cmdlets to take longer? ? My get-tagassignment and new-tagassignment commands takes 11 seconds on my 5.5 production vcenter with 1200 vm's. My beta 6.0 cluster is basically empty but it returns in just a second or two. I just wanted to make sure that the bug wasn't polling mutiple schema entries and that is why my times are longer.
Im having the same problem... been trying to figure out if it was me, or some anomaly in the cmdlet.
Nice to know im not going insane :smileysilly:
Any ideas if this has been logged with VMWare themselves?
Im using VMWare 6.0.0 Build 4192238 if that helps.