Resources for Getting Started with VMware NSX

Resources for VMware NSX

NSX can be a beast to take in at once.  However, as someone trying to get a handle on all that it has to offer, the article below has some great resources to get you started.  No matter what level you are coming into this information at, you will no doubt be able to use these resources to get you started.  And as with anything, practice makes perfect.  So if you’re like me and learn by doing, then hop on over to VMware’s Hands On Labs site and get started with NSX.

Resources for Getting Started with VMware NSX

VMware’s NSX, their Network Virtualization and Security platform is one of their hottest technology platforms. NSX is all about micro segmentation, a policy based method for ensuring resourc…

VMware Social Media Advocacy

Free e-learning course – VMware vSphere: What’s…

Free e-learning course – VMware vSphere: What’s New Fundamentals [V6.0 to V6.5]

Free e-learning course – VMware vSphere: What’s…

This course highlights the new features and enhancements in vSphere 6.5. It also presents use cases that describe how the new features align with customer needs.

VMware Social Media Advocacy

What’s new for vSAN 6.6?

What’s new for vSAN 6.6? []

What’s new for vSAN 6.6?

Yes this may confuse you a bit, a new vSAN release namely vSAN 6.6 but it doesn’t coincide with a vSphere release. That is right, this is a “patch” release for vSphere but a major version for vSAN! It seems like yesterday that we announced 6.2 with Stretched Clustering and 6.5 with iSCSI and 2-Node Direct Connect. vSAN 6.6 brings some exciting new functionality and a whole bunch of improvements. Note that there were already various performance enhancements introduced in vSphere 6.0 Update 3 for vSAN 6.2. Anyway, what’s new for vSAN 6.6?

VMware Social Media Advocacy

VM Delta Migration Procedure

A while back we were charged with moving VMs to a new data center while also keeping downtime to a minimum.  My team and I came up with a VM Delta Migration process to move a delta of the VM (basically the snapshot) so that we could keep the downtime short.  The basic process was to take a snapshot, copy the VM to external media, and power it on.  Then that media was shipped to the new DC to import.  Once imported and ready, we shut down the VM again, SFTP the snapshot files, imported those into the new VM folder and powered on the VM.  Once the VM was powered on and verified working, we were able to remove the snapshot.  I’ve documented the process below for anyone that may be wanting to do something similar.

This article details the steps taken to perform the migration of a large VM in multiple parts – Part 1 is a bulk data copy, sent via physical media for large files. Part 2 is an incremental copy, to allow us to keep the VM available during this window. When the VM is imported at its new home, both parts should be combined.

Step 1:

Power off the VM, and create a snapshot.

Create Snapshot

Step 2:

Browse to the datastore that the VM is located in, and copy all files in the folder to the bulk storage destination. – Delete the VMWare.log files from the destination.

Browse Datastore

Step 3:

Power the VM back on, and ship the physical media over to the new location.

Step 4:

Once the media has been received, power the VM off again, and copy the following files over to the SFTP server:

  • The VMX file
  • The NVRAM file
  • The 000001.vmdk – Snapshot file
  • The –delta.vmdk – Snapshot deltas

Step 5:

At the new data center, copy the files from step 4 to the physical media from step 2. Overwrite any files that are duplicates.

Step 6:

Add all files from the physical media to a datastore, and import the VM using “Add to Inventory” on the .VMX file.

Step 7:

Power the VM online, and once everything is confirmed working, delete the snapshot.


I hope this helps anyone else needing a process to perform a migration of VMs between data centers while keeping downtime to a minimum.

First vSphere Client (HTML5) update in vSphere…

First vSphere Client (HTML5) update in vSphere 6.5.0b! [VMware vSphere Blog]

First vSphere Client (HTML5) update in vSphere…

With the release of vSphere 6.5.0b, we are proud to announce the first update to the vSphere Client!

VMware Social Media Advocacy

Released: vCenter and ESXi 6.0 Update 3 –…

Released: vCenter and ESXi 6.0 Update 3 – What’s in It for Service Providers — via VIRTUALIZATION IS LIFE!

Released: vCenter and ESXi 6.0 Update 3 –…

Last month I wrote a blog post on upgrading vCenter 5.5 to 6.0 Update 2 and during the course of writing that blog post I conducted a survey on which version of vSphere most people where seeing out in the wild…overwhelmingly vSphere 6.0 was the most popular version with 5.5 second and 6.5 lagging in adoption for the moment.

VMware Social Media Advocacy

VMware Security Advisory for ESXi 6.0 and 5.5

Vmware released a new security advisory today advising that ESXi versions 6.0 and 5.5 are vulnerable to Cross-Site Scripting (XSS).  The details of the advisory can be found below as well as the current solution.

Advisory ID: VMSA-2016-0023

Severity:    Important

Synopsis:    VMware ESXi updates address a cross-site

scripting issue

Issue date:  2016-12-20

Updated on:  2016-12-20 (Initial Advisory)

CVE number:  CVE-2016-7463

  1. Summary

VMware ESXi updates address a cross-site scripting issue.


  1. Relevant Releases

VMware vSphere Hypervisor (ESXi)


  1. Problem Description
  1. Host Client stored cross-site scripting issue


The ESXi Host Client contains a vulnerability that may allow for

stored cross-site scripting (XSS). The issue can be introduced by

an attacker that has permission to manage virtual machines through

ESXi Host Client or by tricking the vSphere administrator to import

a specially crafted VM. The issue may be triggered on the system

from where ESXi Host Client is used to manage the specially crafted


VMware advises not to import VMs from untrusted sources.

VMware would like to thank Caleb Watt (@calebwatt15) for reporting

this issue to us.

The Common Vulnerabilities and Exposures project ( has

assigned the identifier CVE-2016-7463 to this issue.


Column 4 of the following table lists the action required to

remediate the vulnerability in each release, if a solution is


VMware  Product Running             Replace with/

Product Version on       Severity    Apply Patch*        Workaround

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

ESXi     6.5    ESXi

N/A        not affected           N/A

ESXi     6.0    ESXi

Important  ESXi600-201611102-SG   None

ESXi     5.5    ESXi

Important  ESXi550-201612102-SG   None

*The fling version which resolves this issue is 1.13.0.


  1. Solution

Please review the patch/release notes for your product and

version and verify the checksum of your downloaded file.


ESXi 6.0





ESXi 5.5





  1. References


Disable the “This host currently has no management network redundancy” message

Let’s go over how to disable the “This host currently has no management network redundancy” message.  It’s annoying and we can get rid of the yellow triangles that show on the hosts due to this message.  And I know, you “should” have redundancy on your management network but we’re just not worried about it.  Our hosts are in our building and not at a co-lo so we have constant access to them in the event something happens and we need access.

Management Network Redundancy WarningSince we don’t care about this warning, I wanted to hide it.  This way we can see if there are actual errors on the host and not some warning about network redundancy.  The fix is done with an advanced option in the cluster properties. In the cluster properties, under vSphere HA, select Advanced Options.  Then add an option named das.ignoreRedundantNetWarning and set the Value to true.

ignoreRedundantNetWarningAnd that’s it! Once the option is in, go to each host and reconfigure for vSphere HA.  The warning will then disappear and your vCenter will look clean again.

Update Manager fails to scan ESXi host

I had an issue when using update manager to scan a host and it would fail with a “Check log for errors blah blah blah”.  The errors are never useful.  After investigating and checking the log, I found the following entry:

2015-06-02T20:57:30.312-07:00 [00504 info ‘VcIntegrity’] Error on logout (ignored): vim.fault.NotAuthenticated

When researching the issue, I came across a best practices guide that basically pointed out the error.  So as a general best practice, verify on your hosts, on the configuration tab, under DNS and Routing, that you have filled in all the fields. I had missed the Search Domain field on that particular host which was causing the scan to fail.

DNS and RoutingThe fields with the blue boxes will cause the Update Manager scan failure as well as cause other issues with DNS on the host.  Just another one of things to check!

As always, leave questions or suggestions in the comments.