Migration from Cisco 1000v to VMware Virtual Distributed Switch (Part 1)

While working with a enterprise customer I was tasked with migrating an entire production environment from the Cisco Nexus 1000v to a VMware Virtual Distributed Switch (VDS). Then moving the VDS and the ESXi 5.1 hosts over to a fresh built vSphere 6.0 server. The customer is in the middle of an upgrade from vCenter 5.1 to 6.0. Most of the host upgrades will be done once the hosts are moved over to to the new vCenter.


  • Non-disruptive migration of networking for Virtual Machines (this is a live production environment)
  • Migrate away from the Cisco 1000v, to VDS
  • Migrate the VDS config from old 5.1 vCenter to new 6.0 vCenter
  • Touch-up naming of virtual machine networks/VLANs
  • Move Virtual Machines from the Virtual Distributed Switch (VDS)/Nexus 1000v to a Virtual Standard Switch (VSS)
  • Disconnect and remove the ESXi hosts from the old vCenter 5.1
  • Connect ESXi hosts to the new vCenter 6.0
  • Migrate VM networking from VSS to VDS

VMware vSphere 5.1 and later allow you to export, import, or restore Distributed Switch configurations from the vSphere Web Client. Since moving the 1000v would be too convoluted, if not actually impossible, I will move everything over to a VDS on the existing 5.1 vCenter first. Then once everything is up and running on the VDS we can then migrate the VDS configuration over to the new 6.0 vCenter server.

000193_2015-10-29 10_06

Unfortunately we will also need to create a Virtual Standard Switch (VSS) switch configured with all the networks, all with matching configuration on each ESXi host in order to actually do the ESXi host migrations over to the new 6.0 vCenter. This will be automated with scripts, of course. We must migrate all virtual machine, VMkernel, and service console networking from VDS to VSS so that network connectivity is not lost when we remove the hosts from the VDS in order to disconnect them from the 5.1 vCenter and add them to the 6.0 vCenter.


The following steps will migrate the host and VM networking from the Cisco Nexus 1000v to a VMware Virtual Distributed Switch. This migration plan assumes that there are at least two dedicated uplinks for VM traffic. The purpose of this is to remove dependencies on the legacy 1000v and create a known working configuration of the VDS that will later migrated to the new vCenter 6.0 server. The customer has decided against using the 1000v and wants it removed from their environments. We need to perform this migration before we can move the hosts to the v6.0 vCenter so that we have a working VDS configuration that we can later export to the new vCenter and as a result have an immediately working VDS configuration.

I performed the migration in two parts; that I named “legs” which is basically a reference to the actual uplinks (A + B) themselves. This is to ensure I can quickly and easily roll-back the change if necessary. For the duration of the migration we will only be on one “leg” at a time (either the 1000v on uplink A – or – the VDS on uplink B), this of course introduces a single point of failure but the risk is acceptable since the change window is quite small and the chances of a switch or uplink failure during our change is low. Regardless, I will ensure that both the 1000v and VDS are fully working at all times until all VM networking is migrated from the 1000v to the VDS – testing along the way to ensure there is no impact to VM networking. Once all VMs are moved from the 1000v then we can remove the uplink to the 1000V which at that point should be completely unused and add that uplink to the VDS so that we can then achieve our A+B uplink redundancy again.

Pre Tasks:

  • *** Disable HA, DRS, and EVC on the Cluster ***
  • *** Storage DRS needs to be set to manual or disabled ***

The following will put the hosts into a split 1000v + VDS configuration. One leg on the 1000v, one leg on the VDS. This is necessary to allow proper configuration verification and full migration of VM networking. During this time however, VMs will only have 1 uplink on either side which introduces a single point of failure. However this will only be for the duration of the migration and then they will move back to 2+ uplink paths.

1 – Place target host into maintenance mode
2 – Remove ONE host uplink to the 1000v
3 – Attach host to new VDS using the now available vmnic that used to be on the 1000v
4 – Remove host from maintenance mode
5 – Use Testing VM to verify networking is working (at your discretion)
6 – Repeat process for all hosts individually

The following will migrate the 2nd leg into the uplink group of the first to allow proper link redundancy on the VDS. Currently VM networking should be working on both the 1000v and VDS. The following steps will fully disconnect the 1000v and migrate VM networking to the VDS. This will allow the removal of the 1000v while the VMs continue running without interruption.

1 – Using the ‘Migrate Virtual Machine Networking’ tool migrate ALL VM networks as required from the 1000v to the VDS networks
2 – Repeat the Migrate Virtual Machine Network for each VM Port Group until all VMs are migrated
3 – ** At this point all VMs should be running from a VDS **
4 – Place target host into maintenance mode
5 – Remove host from the 1000v
6 – Add the vmnic that was on the 1000v to the VDS uplinks
7 – Packet Control (etc) vmnics should show as DOWN on the host
8 – Remove host from maintenance mode
9 – Repeat process for all remaining hosts

Post Tasks:
– Re-enable HA, DRS, EVC, and Storage DRS as appropriate
– Export working VDS configuration to the new v6.0 vCenter server

We’re done!

This migration was completed successfully for the customer in all development, staging, and production VMware environments. During the migration we even took the time to clean-up and standardize the network names of the VM port groups consistently across the environments. I hope this guide can be helpful if you find yourself in a similar situation.

Click here for Part 2, where we will migration the VDS to VSS networking so that we can move the hosts to the new vCenter server, the move back to the VDS on the new vCenter 6.0!

If you have any comments, questions, or suggestions please let me know in the comments section below!


References / Sources:

Automatically reboot an ESXi host after PSOD


Anyone who has worked in a VMware environment for any length of time should be quite familiar with this purple diagnostic screen, or what we like to call the “purple screen of death“.  Even VMware themselves internally reference this setting as “BlueScreenTimeout”, so make no mistake where it’s fathered it’s name. This PSOD screen is what will appear when the ESXi host goes into an unresponsive state.

Note: The default and VMware recommended setting is to leave the host in an unresponsive state with the purple diagnostic screen displayed on the console screen to aid in troubleshooting.

There are some exceptions to VMware’s recommendation on this, mainly for environments or situations where we simply don’t care about what or why the host had a PSOD. We just need it rebooted and be back online and working as soon as possible. Especially if you are using remote syslog on the ESXi host (which you should) this PSOD screen is of trivial importance and just forces manual intervention to have the host rebooted from iLO/IPMI.

If appropriate for your environment lets set a ESXi host to automatically reboot after 120 seconds at the PSOD screen. There are three ways to do this. By SSH or using the “Advanced Settings” window from the vSphere client or vSphere web client.

Using SSH:

  1. Connect to the ESXi host via SSH
  2. Run command:
    • esxcfg-advcfg -s 120 /Misc/BlueScreenTimeout

The value is in seconds before the reboot will occur. Change this as desired.

Using vSphere Client:

  1. Select the host you wish to configure
  2. Go to the Configuration tab, select Advanced Settings
  3. From the Advanced Settings window select “Misc“.
  4. Find the “Misc.BlueScreenTimeout” value.
  5. Enter desired auto reboot time, in seconds.
  6. Click OK to save, and rinse and repeat for other hosts.

000212_2015-11-19 08_39

Using vSphere Web Client (5.x+):

  1. Select the host you wish to configure
  2. Select the Manage Tab. Select “Advanced System Settings”.
  3. Scroll down (or use the filter) to find “Misc.BlueScreenTimeout“.
  4. Click the Edit button. Enter the timeout value, in seconds.

000213_2015-11-19 08_48

Source: http://kb.vmware.com/kb/2042500

Installing open-vm-tools on CentOS


Just a quick post here today. This is in regards to installing open-vm-tools on CentOS. There’s no need to download and install separate epel-release files anymore as it’s now in the CentOS extras repo directly.

To install them, just use this command, then install open-vm-tools.

yum -y –enablerepo=extras install epel-release

– extras is enabled by default but the –enablerepo caters for those that have disabled it.


VMware HTML5 Client?


I’ve caught wind of a real HTML5 web client being developed. Its currently very early into development and is released as technical preview fling. To be clear it’s not for vCenter, but we can only imagine the direction this would eventually go. This version of the ESXi Embedded Host Client is written purely in HTML and JavaScript, and is served directly from your ESXi host. So that means it’s specifically meant to run on the host, and controls only the host but it claims to “perform much better than any of the existing solutions”.

Mainly I am happy to hear that there is no Flash dependency in this version of the web client. Maybe the feedback from customer’s is actually being heard by VMware. Maybe we could see this continue to develop into replacing the vCenter version of the flash web client. We’ll have to wait and see, but for now we know that at least something is being worked on and that is better than nothing.


See full details on the ESXi Embedded Host Client on the VMware Labs website here:


Enable SNMP on ESXi 5.5

000174_2015-07-30 11_27

This is a quick guide on how to configure ESXi 5.5 hosts for SNMP monitoring. I use Observium to monitor and collect information about devices on my home network that support SNMP. This allows me to have an in-depth look at devices on my network as well as see metrics that go far into the past.

First we need to SSH to the ESXi host you would like to enable SNMP on. To do that we first need to make sure that SSH is enabled on the host.

Ensure that SSH is enabled on the ESXi Host:

  1. Go to the configuration tab, then select Security Profile
  2. Select Properties with Services, then select SSH Server
  3. Click the Start button once to start the service for now

000175_2015-07-30 11_33

Using an SSH client, such as Putty, connect to your ESXi host. Then run the following commands:

esxcli system snmp set -c public
esxcli system snmp set -l warning
esxcli system snmp set -e yes

That’s it! You can change the “public” string to whatever your preferred community name is. Now you can disable SSH on the host if you prefer. Then add the host into your SNMP monitoring tool. Wait 5-10 minutes for discovery and your finished.

000173_2015-07-30 11_26

VMUG “Green Out” T-Shirt Design Contest

Today VMUG has announced a new contest to design the new look of the VMUG T-Shirt. If you are the artistic type I would suggest that you give this a go. I am excited to see what people can come up with. They are asking for VMUG members to submit a design or phrase that demonstrates the value of VMUG to you as a member and a VMware customer. Not many other details were provided.

Eligibility: Must be a VMUG member

Deadline: Must submit your entry to [email protected] by 5:00 pm Thursday, June 19th CST
Note: The shirt will include a front graphic only and will be printed in one color. You can download the VMUG logo here.

Copy of the email:
(Click to Enlarge)

000043_2014-06-05 09_30