Changing a virtual machine’s port group via the vSphere Client GUI is simple enough as it’s just 6 clicks but what if you had to change this for 70 virtual machines? Working out the math equates to a total of 420 clicks! This was the situation I was faced with when the master image that was used to deploy XenDesktop 5.5 virtual desktops was assigned the incorrect port group and since there were 70 desktops, I wasn’t too excited about using the GUI to make the change. Enter vSphere 5’s vSphere PowerCLI where all of the repetitive actions we need to perform can be automated with the power of scripting. The following may not be the most elegant solution as I’m in no way an expert with PowerCLI commands since I don’t regularly use it but I hope this will help others like myself who need a quick way to change port group settings for a large amount of virtual machines.
The first thing you’ll need to do is organize the virtual machines you need to make this change into a folder so you can reference this folder when executing the PowerCLI command:
Note too appealing is it?
Open up the vSphere PowerCLI window and begin by typing in the following command:
Connect-VIServer yourVcenterFQDN
From here, we’ll first try listing out the virtual machines that we’ll be changing the port group for via the Get-VM command. More information about this command can be found @ the following link: http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Get-VM.html
Get-VM -Location “XenDesktop VDI Master Images”
This step is important because you should review what is actually being listed to ensure you don’t accidentally change the port group of a virtual machine you don’t want to.
So the change we want to make is to change the port group from a regular vSwitch’s VM Network:
… to a port group on a dvSwitch named:
dvPortGroup_130
Note that the name of the port group does not include the (dvSwitch_Production)
The next 2 commands we’ll be using are:
- Set-VM
- Get-NetworkAdapter
More information about these 2 commands can be found here:
Set-VM: http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Set-VM.html
Get-NetworkAdapter: http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Get-NetworkAdapter.html
As yet another sanity and validation check, execute the following command to confirm that the virtual machines our Get-VM is returning is set to the port group that we want to change:
Get-VM -Location “XenDesktop VDI Master Images” | Get-NetworkAdapter
Note how some of the line items have the dvPortGroup listed as the NetworkName. This is because some of the virtual machines from our Get-VM command already has the correct port group set.
The next command we’ll be using is the Set-NetworkAdapter (more information about this command can be found here: http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Set-NetworkAdapter.html) which will allows us to set the port group by piping in the information we’ve retrieved in the previous commands.
Get-VM -Location “XenDesktop VDI Master Images” | Get-NetworkAdapter | Where {$_.NetworkName -eq “VM Network”} | Set-NetworkAdapter -NetworkName “dvPortGroup_VDI130” -Confirm:$false
Notice how I included the additional:
Where {$_.NetworkName -eq “VM Network”}
… which his used so that we only change the port groups for the virtual machines that are set to VM Network.
The additional switch at the end:
-Confirm:$false
… is used so that you will not be asked whether you *really* want to change the port group settings for each virtual machine.
Once you execute the command, you’ll see the status being displayed:
Upon completion, you’ll see the list of virtual machines’ adapters with the new port groups set:
If you had your vSphere client up during the change, you should see the Recent Tasks window list the changes:
As a sanity check because it’s always scary when you perform bulk updates like this is to have a look at the task history to ensure you did not inadvertently change the port group for virtual machines you didn’t want:
Now in the case of my virtual desktops, since they were assigned to an incorrect port group that had a DHCP server handing out IP addresses, all of them still retained the old IP address. The quick and easy way to correct this is to either reboot the virtual machines via the vSphere Client or Desktop Studio GUI:
… or disconnect and reconnect their NICs. I choose the later as I had some users on the virtual machines and did not want to create a boot storm either. The following shows a way to disconnect and reconnect the NICs with a command:
Get-VM -Location “XenDesktop VDI Master Images” | Get-NetworkAdapter | Set-NetworkAdapter -Connected $false -Confirm:$false
Note that if you had some virtual machines turned off, you will get errors and warnings that looks something like this:
There isn’t really any harm since the command will just skip the virtual machine but a more elegant way to do it is to put a Where clause as I did earlier to skip powered off virtual machines.
Once all of the NICs have been disconnected, proceed with executing the following command with the connected switch set to true:
Get-VM -Location “XenDesktop VDI Master Images” | Get-NetworkAdapter | Set-NetworkAdapter -Connected $true -Confirm:$false
Again, if you had powered off virtual machines, you’d have errors thrown:
Not much to it once you get the hang of it but I’m sure I will forget this in the future so this blog will serve as something I can reference to in the future.
