Just a heads up for anyone that creates PowerCLI scripts and depends on them for automation efforts.
The scenario:
$folderView = get-folder myvmfolder | get-view
get-view -viewtype virtualmachine -filter @{"parent"=$folderView.moref.value}
Returns VMs in the folder as expected
get-view -viewtype virtualmachine -filter`
@{"parent"=$folderView.moref.value;"config.template"="False"}
Using any additional filter along with the parent property results in additional VMs being listed that are not actually located in the VM folder myvmfolder.
get-vm vm-x | get-view
Results for one of the unexpected VMs shows no value in the parent property
Talked to vCenter admin in charge of the particular system. Noticed that the PowerCLI user I was running the scripts as has read access to view the other VMs Resource Pool, but not read access to view the VM folder where the extra VMs reside. In other words I don't get any results from running get-folder otherfolder. The other VM results recently showed up when running a set of PowerCLI scripts. The other VMs were recently unregistered from a vCenter 3.5 system and registerd on the vCenter 4.1 system by one of the admins.
Code fix to ensure all of the get-view commands filter only specified folder VMs as expected and not grab other VMs that have a null parent property. I'd rather fix the original script to account for the unexpected configuration since the scripts are distributed across the organization for use on multiple vSphere systems.
get-view -viewtype virtualmachine -filter`
@{"parent"=$folderView.moref.value;"config.template"="False"}`
| where {$_.parent -ne $null}
Sort of odd, not sure if its a bug. If I specify the parent shouldn't PowerCLI reject entries with $null parent properties? Anyhow have a band aid fix for now in the interim.
