WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Automate the migration from Virtual Standard Switch to vSphere Distributed Switch using PowerCLI 5.5

10.31.2013 by William Lam // 22 Comments

I have been spending quite a bit of time in the lab lately working with some of our "future" software and one of the fun tasks I get to do is perform frequent rebuilds of my lab environment. Depending on the issues I encounter, I may even need to rebuild it on a daily basis and of course I have the majority of this automated so it is not as painful as it would be if I had to go through this manually.

The output of this build is a complete working vSphere environment that consists of several ESXi hosts connected to a vCenter Server with all the network and storage configured. On the networking front, the ESXi hosts were all running on a regular Virtual Standard Switch (VSS) and I needed to migrate them over to a Virtual Distributed Switch (VDS). In this particular environment, there is some Windows infrastructure and I thought about the different ways I could accomplish this and I remember hearing about some new VDS cmdlets that came out of PowerCLI 5.5. release.

Since I already had some scripts being kicked off on this Windows system, I thought I give the new PowerCLI cmdlets a try for VSS->VDS migration as I have heard good things about the new cmdlets. I performed my prototyping on a vSphere 5.5 environment, but I believe you might even be able to use this on older releases of vSphere.

Here is a list of the new VDS cmdlets that I used for the script:

  • New-VDSwitch
  • Get-VDSwitch
  • New-VDPortgroup
  • Add-VDSwitchVMHost
  • Add-VDSwitchPhysicalNetworkAdapter

Here are additional vSphere networking cmdlets that were required for script:

  • Get-VMHostNetworkAdapter
  • Set-VMHostNetworkAdapter
  • Get-VirtualSwitch
  • Get-VirtualPortGroup
  • Remove-VirtualPortGroup

Even as a beginner of PowerCLI, I was able to quickly knock out a script that performed the migration from VSS to VDS and was able migrate ALL VMkernel interfaces and physical interfaces without any downtime. These new cmdlets definitely make it very easy for administrators to go from old Virtual Standard Switch over to the vSphere Distributed Switch.

Here is a overview of what my environment looks like which consists of three ESXi hosts with four physical NICs and three VMkernel interfaces.

The script below will create a brand new VDS and their associated Distributed Portgroups and attach a list of ESXi hosts which is configurable and performs the migration of VMkernel and physical interfaces. It does this by first moving two of the four physical NICs to the new VDS to ensure connectivity and then starts the migration of all VMkernel interfaces. Once that is complete, it will move the remainder physical NICs and then delete the Virtual Stand Switch portgroups.

Disclaimer: Please ensure you test this script in a development/test lab before using it in a production environment.

Connect-VIServer -Server vcenter55-1.primp-industries.com -User *protected email* -Pass vmware

# ESXi hosts to migrate from VSS->VDS
$vmhost_array = @("vesxi55-1.primp-industries.com", "vesxi55-2.primp-industries.com", "vesxi55-3.primp-industries.com")

# Create VDS
$vds_name = "VDS-01"
Write-Host "`nCreating new VDS" $vds_name
$vds = New-VDSwitch -Name $vds_name -Location (Get-Datacenter -Name "VSAN-Datacenter")

# Create DVPortgroup
Write-Host "Creating new Management DVPortgroup"
New-VDPortgroup -Name "Management Network" -Vds $vds | Out-Null
Write-Host "Creating new Storage DVPortgroup"
New-VDPortgroup -Name "Storage Network" -Vds $vds | Out-Null
Write-Host "Creating new vMotion DVPortgroup"
New-VDPortgroup -Name "vMotion Network" -Vds $vds | Out-Null
Write-Host "Creating new VM DVPortgroup`n"
New-VDPortgroup -Name "VM Network" -Vds $vds | Out-Null

foreach ($vmhost in $vmhost_array) {
# Add ESXi host to VDS
Write-Host "Adding" $vmhost "to" $vds_name
$vds | Add-VDSwitchVMHost -VMHost $vmhost | Out-Null

# Migrate pNIC to VDS (vmnic0/vmnic1)
Write-Host "Adding vmnic0/vmnic1 to" $vds_name
$vmhostNetworkAdapter = Get-VMHost $vmhost | Get-VMHostNetworkAdapter -Physical -Name vmnic0
$vds | Add-VDSwitchPhysicalNetworkAdapter -VMHostNetworkAdapter $vmhostNetworkAdapter -Confirm:$false
$vmhostNetworkAdapter = Get-VMHost $vmhost | Get-VMHostNetworkAdapter -Physical -Name vmnic1
$vds | Add-VDSwitchPhysicalNetworkAdapter -VMHostNetworkAdapter $vmhostNetworkAdapter -Confirm:$false

# Migrate VMkernel interfaces to VDS

# Management #
$mgmt_portgroup = "Management Network"
Write-Host "Migrating" $mgmt_portgroup "to" $vds_name
$dvportgroup = Get-VDPortgroup -name $mgmt_portgroup -VDSwitch $vds
$vmk = Get-VMHostNetworkAdapter -Name vmk0 -VMHost $vmhost
Set-VMHostNetworkAdapter -PortGroup $dvportgroup -VirtualNic $vmk -confirm:$false | Out-Null

# Storage #
$storage_portgroup = "Storage Network"
Write-Host "Migrating" $storage_portgroup "to" $vds_name
$dvportgroup = Get-VDPortgroup -name $storage_portgroup -VDSwitch $vds
$vmk = Get-VMHostNetworkAdapter -Name vmk1 -VMHost $vmhost
Set-VMHostNetworkAdapter -PortGroup $dvportgroup -VirtualNic $vmk -confirm:$false | Out-Null

# vMotion #
$vmotion_portgroup = "vMotion Network"
Write-Host "Migrating" $vmotion_portgroup "to" $vds_name
$dvportgroup = Get-VDPortgroup -name $vmotion_portgroup -VDSwitch $vds
$vmk = Get-VMHostNetworkAdapter -Name vmk2 -VMHost $vmhost
Set-VMHostNetworkAdapter -PortGroup $dvportgroup -VirtualNic $vmk -confirm:$false | Out-Null

# Migrate remainder pNIC to VDS (vmnic2/vmnic3)
Write-Host "Adding vmnic2/vmnic3 to" $vds_name
$vmhostNetworkAdapter = Get-VMHost $vmhost | Get-VMHostNetworkAdapter -Physical -Name vmnic2
$vds | Add-VDSwitchPhysicalNetworkAdapter -VMHostNetworkAdapter $vmhostNetworkAdapter -Confirm:$false
$vmhostNetworkAdapter = Get-VMHost $vmhost | Get-VMHostNetworkAdapter -Physical -Name vmnic3
$vds | Add-VDSwitchPhysicalNetworkAdapter -VMHostNetworkAdapter $vmhostNetworkAdapter -Confirm:$false

# Remove old vSwitch portgroups
$vswitch = Get-VirtualSwitch -VMHost $vmhost -Name vSwitch0

Write-Host "Removing vSwitch portgroup" $mgmt_portgroup
$mgmt_pg = Get-VirtualPortGroup -Name $mgmt_portgroup -VirtualSwitch $vswitch
Remove-VirtualPortGroup -VirtualPortGroup $mgmt_pg -confirm:$false

Write-Host "Removing vSwitch portgroup" $vmotion_portgroup
$vmotion_pg = Get-VirtualPortGroup -Name $vmotion_portgroup -VirtualSwitch $vswitch
Remove-VirtualPortGroup -VirtualPortGroup $vmotion_pg -confirm:$false

Write-Host "Removing vSwitch portgroup" $storage_portgroup
$storage_pg = Get-VirtualPortGroup -Name $storage_portgroup -VirtualSwitch $vswitch
Remove-VirtualPortGroup -VirtualPortGroup $storage_pg -confirm:$false
Write-Host "`n"
}

Disconnect-VIServer -Server $global:DefaultVIServers -Force -Confirm:$false

Here is a screenshot of running through the script:

If we now take a look at our enviornment, we can see all three ESXi hosts have been migrated over to the VDS.

UPDATE (11/4/13) -  Thanks to one of the PowerCLI engineers, it looks like there is a PowerCLI cmdlet that can be used to migrate from VDS->VSS. I will be sharing that script in another blog post for those that may want to perform the reverse.

One caveat that I hit during the development of this script is needing the ability to easily migrate between VSS->VDS and VDS->VSS. I was hoping it was simply reversing the set of operations and moving the VMkernel interfaces back to the Virtual Standard Switch but what I found for the Set-VMHostNetworkAdapter cmdlet is that it only accepts a Distributed Virtual Portgroup. This meant that I could only migrate to a VDS but not to a VSS. Though this will probably will fit the majority of customer use cases, for me this was a problem and means I will need to dig into the vSphere APIs to be able to seamlessly perform a VDS->VSS migration. Given that PowerCLI is an abstraction, we should be able to easily add this feature and I will be filing an FR with Engineering to see if we can get this added as I think it would be a useful feature to have.

Categories // PowerCLI, Uncategorized Tags // distributed virtual switch, migration, PowerCLI, vds, vSphere 5.5, vss

Quick Tip - Connecting to multiple View Brokers using Horizion View Client on Mac OS X

10.30.2013 by William Lam // 2 Comments

On a regular basis, I will remote into at least 3 to 4 different lab environments where desktops are serviced through different Horizon View brokers. Being within VMware R&D, I get to work on a variety of projects and that means I need to jump in and out of an environment for development, troubleshooting, reproduction, etc. I recently upgraded my View Client 1.3 (before the name change) to the latest Horizon View Client which is now 2.1 and to my surprise I found that I could no longer simultaneously connect to multiple desktops from different View brokers. I have been using this feature for quite some time and I was just surprised to see it gone.

For those of you who have not used this before, you used to be able to create "New Connection" while being connected to a desktop as seen in the screenshot below.

In the latest Horizon View Client, this option is now grayed out.

One new feature that was added in the latest version of the Horizon View Client is the ability to connect to multiple desktops from the same View broker which can come handy. However, for my particular use case this is a set back and disconnecting/reconnecting is just not ideal, especially when I know I need to context switch between two desktops.

A workaround that would allow you to connect to different desktops from different View brokers is to launch the first instance of Horizion View Client from the launch pad. Once the first instance is running, you will then need to open a terminal and run the following command which will launch additional instances of the Horizon View Client:

"/Applications/VMware Horizon View Client.app/Contents/MacOS/vmware-view"

I have been told this feature was removed in the 1.4 release of View Client due to some performance issues found in Mac OS X RDP sessions. I hope this will eventually be fixed as it was a really nice feature to have. For now, you will need to use the work around if you need to connect to multiple View brokers. For myself personally, I have decided to downgrade back to version 1.3 release, unfortunately this build is no longer available for public download.

Categories // Horizon View Tags // horizon view client, osx, vmware view

Quick Tip - Using the CLI to upgrade to a specific VM virtual hardware version in vSphere 5.5

10.30.2013 by William Lam // 4 Comments

For those of you who usually use the "legacy" vSphere C# Client to perform virtual machine virtual hardware upgrade (also known as Virtual Machine Compatibility) should know that the default behavior is to automatically upgrade to the latest supported version. This is usually not an issue, however with vSphere 5.5 if you do perform this upgrade, one caveat to be aware of that you will NOT be able to edit the virtual machine configurations using the vSphere C# Client afterwards. A confirmation dialog is even presented to warn the user before performing this operation and that the virtual machine can only be manage through the vSphere Web Client.

Note: Even though the virtual machine settings can not be managed/configured using the vSphere C# Client, you can still use the various vSphere API/CLIs to manage the virtual machine and those are fully supported.

I had noticed a couple of comments on Twitter the other day and even at VMworld Barcelona that this was not ideal that the vSphere C# Client automatically upgraded to the latest version. I know there are some folks that would have liked to upgrade to a specific version of virtual hardware. Luckily, you can easily do so by using the vSphere API/CLI such as PowerCLI for example if you have paid vSphere license.

You can use the Set-VM cmdlet and  specify the -Version property, here is the syntax for the command:

Set-Vm -VM (Get-VM -Name [VM-NAME]) -Version v[HW-VERSION]

Here is a screenshot of upgrading a VM called "Duncan" from vHW8 to vHW9:

Now this is great for customers who have a vSphere license that allows for both read/write access to the APIs which PowerCLI and other CLIs leverage. For customers using Free ESXi or just want a quick and simple way of upgrading to a specific virtual hardware version, you can leverage vim-cmd utility which is found in the ESXi Shell.

You can use the following command to upgrade to a specific virtual hardware version (you will need to specify the VM-ID by using vim-cmd vmsvc/getallvms):

vim-cmd vmsvc/upgrade [VM-ID] vmx-[HW-VERSION]

Here is a screenshot of upgrading a VM called "Cormac" from vHW7 to vHW9:

Categories // Uncategorized Tags // ESXi 5.5, virtual hardware, virtual hardware 10, vmx-10, vSphere 5.5, vsphere C# client, vsphere web client

  • « Previous Page
  • 1
  • …
  • 435
  • 436
  • 437
  • 438
  • 439
  • …
  • 565
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • PowerCLI remediation script for running NSX Edge on AMD Ryzen for VCF 9.0 06/20/2025
  • Failed to locate kickstart on Nested ESXi VM CD-ROM in VCF 9.0 06/20/2025
  • NVMe Tiering with Nested Virtualization in VCF 9.0 06/20/2025
  • VCF 9.0 Installer workaround for ESXi hosts with different vendor 06/19/2025
  • NVMe Tiering with AMD Ryzen CPU workaround for VCF 9.0 06/19/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025