As long as the VMs are powered on they will display the "old" name in the Settings.
I suspect that's because the name is just a property of the portgroup.
Internally ESX doesn't use the actual name to find out which portgroup is connected to a VM.
If the guest is restarted you will see the "new" portgroup name.
And that is probably because at that point the vSphere client reads all the properties for the connected devices.
____________
Blog: LucD notes
Twitter: lucd22
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
How did you change the portgroupname ?
With PowerCLI
Get-VMHost <esx-name> | Get-VirtualPortGroup -Name <current-pg-name> | Set-VirtualPortGroup -Name <new-pg-name>
or did you use the UpdatePortGroup method ?
$oldName = <current-pg-name> $newName = <new-pg-name> $esx = Get-VMHost <esx-name> | Get-View $netSys = Get-View $esx.ConfigManager.NetworkSystem $pg = $esx.Config.Network.Portgroup | where {$_.Spec.Name -eq $oldName} $spec = $pg.Spec $spec.Name = $newName $netSys.UpdatePortGroup($oldName, $spec)
____________
Blog: LucD notes
Twitter: lucd22
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
HI and thanks
I understand both of them (at least i think so)
But my question is what will happen to all the VM's that are connected to this portgroup?
As long as the VMs are powered on they will display the "old" name in the Settings.
I suspect that's because the name is just a property of the portgroup.
Internally ESX doesn't use the actual name to find out which portgroup is connected to a VM.
If the guest is restarted you will see the "new" portgroup name.
And that is probably because at that point the vSphere client reads all the properties for the connected devices.
____________
Blog: LucD notes
Twitter: lucd22
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
I'm about to rename quite a few of our portgroups to match our naming convention. Given the second method is more complex (compared to the one liner) is there are reason to use it? Any difference in the two approaches?
Thanks,
Ed.
No, use the first method.
The 2nd method is the SDK based and was used when previous builds of PowerCLI didn't have the feature yet.
____________
Blog: LucD notes
Twitter: lucd22
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Thanks for the quick reply, much appreciated. Presumably I'll need to
recurse through all our hosts to see which have that portgroup
defined? Is there a more efficient way - do the properties of a
portgroup include the hosts using it? I 'm guessing not.
Regards
Ed
Sent from my iPhone
A quick way to find all the hosts that have a portgroup with a specific name is the following
$pgName = "MyPG" Get-VMHost | %{ if($_ | Get-VirtualPortGroup -Name $pgName -ea SilentlyContinue){ $_.Name } }
Note the -ea (-ErrorAction) parameter. It avoids error messages for those host where the portgroup is not present.
____________
Blog: LucD notes
Twitter: lucd22
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Fab, thanks!
Sent from my iPhone
Interestingly Luc's earlier comment about not needing to change the VM properties doesn't seem correct. If I change the
portgroup name (using Get-Host | Get-VirtualPortGroup |
Set-VirtualPortGroup -Name) and then check the VM settings the entry
for the relevant network card name is indeed blank. The problem is that
if I restart the VM (or even if I power off then back on) the NIC still
shows a blank entry and is disconnected. This means if you don't follow up and rename the portgroup settings for the VMs they'll drop off the network on the next reboot. I'm testing this on vSphere
4.0U1.Here's another thread with a similar conclusion.
It also means the 'network' view in the VI client is
misleading - both the old and new network (portgroup) names are shown
and the VMs are shown (correctly) as being attached to the old network.The fix is to change the host portgroups using Luc's code and then update all the VMs to reflect the correct portgroup name - Al Renouf has already covered how to update multiple VMs, see this thread.
Regards,
Ed