• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

virtuallyGhetto

  • About
  • Privacy
  • VMware Cloud
  • Home Lab
  • Nested Virtualization
  • Automation
    • VMware Kickstart
    • VMware API/SDK/CLI
    • VMware vMA/VIMA
    • VMware OVF / OVFTOOL
  • Apple Mac
  • VCSA
  • VSAN

PowerCLI

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.

PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
Connect-VIServer -Server vcenter55-1.primp-industries.com -User administrator@vsphere.local -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.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: PowerCLI, Uncategorized Tagged With: distributed virtual switch, migration, PowerCLI, vds, vSphere 5.5, vss

Automate Enabling VM Storage Profiles Capability in vSphere

08/06/2013 by William Lam 1 Comment

I recently had to rebuild one of my lab environments that consisted of a vCenter Server and several ESXi hosts and one of the capabilities I required was VM Storage Profiles. In a brand new vSphere environment, VM Storage Profiles is disabled by default, presumably due to licensing as this feature is not available in every SKU. To enable VM Storage Profiles, you will need to connect to your vCenter Server using either the vSphere Web Client or the legacy vSphere C# Client as seen in the screenshot below.

Another way of enabling the VM Storage Profiles feature is through an automated fashion using the vSphere APIs where this functionality is exposed.

Note: To manage and consume VM Storage Profiles, you will still need to use the vSphere Web Client or vSphere C# Client as the APIs for this functionality is not yet available.

VM Storage Profiles is enabled on a per vSphere Cluster basis and there is a boolean property called spbmEnabled which determines whether this feature is enabled or disabled. To update this property, you will need to use the ReconfigureComputeResource_Task method.

Here is are two examples of implementing the API both in a PowerCLI script as well as a vSphere SDK for Perl script:

PowerCLI:

In my lab environment, I have a vSphere Cluster called "Cluster" and you can use PowerCLI to check whether VM Storage Profiles is enabled or not by running this command (replace Cluster with the name of your vSphere Cluster):

(Get-Cluster -Name Cluster).extensionData.ConfigurationEx.SpbmEnabled

To enable VM Storage Profiles, you can then call the Enable-StorageProfile function along with the name of the vSphere Cluster which is just called "Cluster":

 

vSphere SDK for Perl:

To enable VM Storage Profiles using the vSphere SDK for Perl, I wrote a quick script called storageProfileMgmt.pl which allows you to query whether a vSphere Cluster has VM Storage Profiles as well as enabling and disabling the feature. Here is a screenshot demonstrating how the script works:

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Uncategorized Tagged With: PowerCLI, spbm, Storage Policy Based Management, vm storage profile, vsphere sdk for perl

Extracting SSL Thumbprint from ESXi

04/15/2012 by William Lam 12 Comments

While browsing the VMTN forums earlier this week, I noticed an interesting request from a user who was trying to compile an inventory of the SHA1 Thumbprints for all his ESXi hosts. The challenge the user had, was that he was capturing this information manually by "looking" at the DCUI screen which is where the SHA1 Thumbprint for an ESXi host is displayed by default.

As you might have guessed, this can be very tedious and error prone by copying down this very long string by just looking at the screen. Even if you do not make a mistake copying this long string, I bet your eyes will eventually give out. Luckily, there are a few ways to retrieve this information and I will show you some methods to help automate this across all of your ESXi hosts.

UPDATE (05/22/16) - Here's how you can extract SSL Thumbprint using PowerShell

Option 1 - Retrieve SSL Thumbprint using the DCUI as shown above, this is going to be the most manual method.

Option 2 - If you have remote SSH or direct console access to ESXi Shell, you can login to your ESXi host and using openssl utility, you can retrieve the SSL Thumbprint which you can then use or copy off to a remote host.

openssl x509 -in /etc/vmware/ssl/rui.crt -fingerprint -sha1 -noout

Option 3 - You can remotely retrieve the SSL Thumbprint by leveraging just the openssl utility and you do not even need to login to the ESXi host. This not only allows you to retrieve the SSL Thumbprint from a centralized location, but you can easily automate this across all your hosts.

echo -n | openssl s_client -connect 172.30.0.252:443 2>/dev/null | openssl x509 -noout -fingerprint -sha1

Using Option 3, you can easily wrap this in a simple "for" loop to iterate through all your ESXi hosts as long as you have either the hostname/IP Address. Here is a simple shell script that you can use to iterate through all your ESXi hosts to extract the SSL Thumbprint.

In the script above, I have a list of three ESXi hosts and it is simply going through each host and executing the two commands to extract the SSL Thumbprint and displaying it on the screen.

Option 4 - You can also retrieve the SSL Thumbprint using the vSphere API, but the property is only displayed when it is connected to a vCenter Server. There is a property on the ESXi host called sslThumbprint that is populated when querying against the vCenter Server that is managing the ESXi host. You can use the vSphere Health Check script which captures this and other useful information about your vSphere infrastructure.

As you can see, there are several options on obtaining the SSL Thumbprint for an ESXi host, you definitely do not have to manually read it off the DCUI screen. Automation FTW again! 🙂

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, ESXi Tagged With: esxi 5, esxi4, PowerCLI, powershell, sha1, ssl certificate, thumbprint

Automate Update Manager Operations using vSphere SDK for Perl + VIX + PowerCLI + PowerCLI VUM

07/30/2010 by William Lam Leave a Comment

I recently saw an interesting question on the VMTN developers forum asking about vSphere SDK for Perl and VUM API integrations. As it stands today, VMware has not publicly exposed or documented the VMware Update Manager APIs, though they have released a few PowerCLI VUM cmdlets for PowerCLI users. This is one feature, in my opinion, that PowerCLI has over the other vSphere SDKs. This is quite unfortunate, since automating VUM operations is something I have looked forward to and the process can be slow from clicking around in the GUI. I think VMware sometimes forget that the world does not run on Windows and that VMware != Windows.

I was hoping with the release of vSphere 4.1, the VUM APIs would finally be exposed as a standard web service like the vSphere API provided with proper SDKs for the various languages. My reply to the VMTN user was exactly this: this type of integration does not exist today. If you would like to automate VUM operations, you must use the PowerCLI VUM cmdlets. The follow-up comment was how one might integrate between vSphere SDK for Perl and PowerCLI VUM cmdlets. Initially, I did not recommend this but it could potentially work with some type of WMI call or hooks from some Perl modules. The solution might get a little messy and it would probably be faster to just set up the PowerCLI VUM cmdlets on a Windows host.

As I thought about the question later that evening, I realized that there is potentially another method if you wanted to use the vSphere SDK for Perl but utilize the PowerCLI VUM cmdlets. The following solution will demonstrate the use of vMA, vSphere SDK for Perl, VIX Perl API, PowerCLI and PowerCLI VUM cmdlets. VMware VIX is used for guest management for VMs running on a VMware hypervisor, whether it be Workstation, Fusion or ESX(i). There is a Perl SDK for the VIX API which I use to generate a PowerCLI script that is transferred directly into a Windows VM running both PowerCLI and PowerCLI VUM. This dynamic PowerCLI script will contain the host information and VUM baseline provided from the vSphere SDK for Perl script. The script will remediate the host and then it will be deleted by VIX. This configuration is not ideal, but if you wanted to automate some of the available VUM operations but continue to use your vSphere SDK for Perl scripts, then you can.

The dynamic PowerCLI script that is generated is the following:

Connect-VIServer -Server [vc-server] -Protocol https -User [vc-user] -Password [vc-password]
$vmhost = Get-VMHost [vi-host]
$baseline = Get-Baseline [host-baseline]
$baseline | Attach-Baseline -Entity $vmhost -Confirm:$false
$vmhost | Scan-Inventory
$baseline | Remediate-Inventory -Entity $vmhost -Confirm:$false

Note: This is just one example, you can easily customize the script to generate other VUM operations or more complex PowerCLI script. Once the operation is completed on the ESX(i) host, the script is deleted via VIX.

Before we get started, you will need to have a Windows VM that has both PowerCLI and PowerCLI VUM installed which resides in the same infrastructure as your VUM Server. You will also need to have VMware vMA available and installed with VMware VIX which will be documented down below.

1. Download VMware VIX 1.10

2. Transfer VMware-VIX-1.10.1-266898.x86_64.bundle installer to vMA

3. Install VIX:

VMware-VIX-1.10.1-266898.x86_64.bundle

================================================================

[[email protected] ~]$ sudo sh VMware-VIX-1.10.1-266898.x86_64.bundle
Password:
Extracting VMware Installer...done.
You must accept the VMware VIX API End User License Agreement to
continue. Press Enter to proceed.
.....
The product is ready to be installed. Press Enter to begin
installation or Ctrl-C to cancel.
Installing VMware VIX API 1.10.1
Configuring...
[######################################################################] 100%
Installation was successful.

To complete the next section, you will need GCC to be installed which is not part of the default vMA installation. If you are using vMA 4.1, it is running CentOS and you can setup CentOS YUM repository. This will require that your vMA host can proxy out to internet or to specific site. I will document the changes that need to be made to talk to CentOS repository for package installs.

4. Create repository file:

[[email protected] ~]$ sudo vi /etc/yum.repos.d/centos-base.repo

Add the following to the repo file:

5. Install GCC using yum:

[[email protected] ~]$ sudo yum -y --nogpgcheck install gcc.x86_64

6. CD to vmware-vix directory and extract VIX Perl

[[email protected] ~]$ cd /usr/lib/vmware-vix/

[[email protected] vmware-vix]$ sudo tar -zxvf vix-perl.tar.gz
vix-perl/
vix-perl/vix.h
vix-perl/includeCheck.h
vix-perl/vm_basic_types.h
vix-perl/VixBinding.xs
vix-perl/VixBinding.pm
vix-perl/ModuleList
vix-perl/lib/
vix-perl/lib/API/
vix-perl/lib/API/API.pm
vix-perl/lib/API/Host.pm
vix-perl/lib/API/Job.pm
vix-perl/lib/API/VM.pm
vix-perl/lib/API/Snapshot.pm
vix-perl/lib/API/PropertyList.pm
vix-perl/lib/API/Constants.pm
vix-perl/lib/Simple.pm
vix-perl/Makefile.PL
vix-perl/typemap
vix-perl/ppport.h
vix-perl/README
vix-perl/samples/
vix-perl/samples/findhosttest.pl
vix-perl/samples/powertest.pl
vix-perl/samples/vmrun.pl
vix-perl/libvixAllProducts.so

7. Install VIX Perl

[[email protected] vmware-vix]$ cd vix-perl

[[email protected] vix-perl]$ sudo perl Makefile.PL
Writing Makefile for VMware::VixBinding

[[email protected] vix-perl]$ sudo make

[[email protected] vix-perl]$ sudo make install

If you did not want to go through all these manual steps after installing VIX, I actually wrote a quick shell script that will automate the configuration of the CentOS repository, GCC installation and extraction and installation of VIX Perl.

Download installVIXPerl.sh

Executing installVIXPerl.sh:

[[email protected] ~]$ chmod +x installVIXPerl.sh

[[email protected] ~]$ sudo ./installVIXPerl.sh

9. Download patch-host.pl script and transfer it to vMA

10. You will need to edit 4 variables defined within the script:

$psvm_username = Is the username to your Windows system running PowerCLI
$psvm_password = Is the password to your Windows system running PowerCLI
$powercli_bin = Is the full path to your powershell binary, if it is a default installation, you can leave this unchanged
$powercli_options = Is the path to vSphere PowerCLI psc file, you can also leave this as the default

Note: If you do decide to change either $powercli_bin or $powercli_options, make sure you add an extra "forward slash" which needs to be escaped in the Perl script.

The script requires you to connect to your vCenter server and provide the following parameters:

--vihost = Name of ESX(i) host to be patched

--baseline = Name of the VUM basline to attach

--psvm = Name of the Windows VM running both PowerCLI and PowerCLI VUM

Here is an example patching an ESXi host that is running on 4.0u2 and using the script to apply vSphere 4.1 baseline:

[[email protected]]$ ./patch-host.pl --config --server reflex.primp-industries.com --username primp --vihost esxi4-3.primp-industries.com --psvm powerclivm --baseline vSphere4.1-Upgrade

Entering maintenance mode for esxi4-3.primp-industries.com
Successfully entered maintenance mode for esxi4-3.primp-industries.com
Guest login successfully!
Copy patch-host-esxi4-3.primp-industries.com-22174.ps1 to guest successfully!
PowerCLI/VUM script executed successfully!
Script removed successfully!
Successfully patched esxi4-3.primp-industries.com using VUM baseline: vSphere4.1-Upgrade

One thing I did notice, after the script is transferred to the Windows VM, it takes about 15-20 seconds before the script executes. I am not exactly sure why this occurs, as this does not happen when running the PowerCLI script logged into the VM. This may be due to the way VIX is executing the script within the guest.

The following resources were used in creating this script:

  • Referenced growdisk.pl vSphere SDK for Perl/VIX script written by Matt Lamantia
  • Referenced Alan's video on Getting Started with Update Managed cmdlets
Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: PowerCLI, Uncategorized Tagged With: PowerCLI, vix, vsphere sdk for perl, vum

  • « Go to Previous Page
  • Go to page 1
  • Interim pages omitted …
  • Go to page 17
  • Go to page 18
  • Go to page 19

Primary Sidebar

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Services Business Unit (CSBU) at VMware. He focuses on Automation, Integration and Operation for the VMware Cloud Software Defined Datacenters (SDDC)

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Sponsors

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