Offline upgrade of ESXi hosts to 5.5 U2

This is a quick post to show you how to upgrade your ESXi hosts to vSphere 5.5 U2 without the use of vCenter Update Manager, and also to remind me for later updates.  I currently use vCenter Update Manager to upgrade my production hosts but it's not worth deploying another instance for my nested environment and unfortunately you can only have one vCenter Update Manager per vCenter instance.  So, first thing to do is download the vSphere 5.5 U2 offline bundle:

Next you need to upload the offline bundle .zip to a datastore that's accessible by all ESXi hosts that you wish to upgrade.  In my example I'm going to use IX2-ISCSI-TestLab:

Once the .zip is uploaded place the host you wish to upgrade into maintenance mode and SSH into the host and run the following command to list the image profiles that are in that offline bundle:

esxcli software sources profile list -d /vmfs/volumes/IX2-ISCSI-TestLab/update-from-esxi5.5-5.5_update02-2068190.zip

Select the profile that you want to install and run the following command:

esxcli software profile update -d /vmfs/volumes/IX2-ISCSI-TestLab/update-from-esxi5.5-5.5_update02-2068190.zip -p ESXi-5.5.0-20140902001-standard

Once completed you will be instructed to reboot the host:

Once the host reboots the version should now show as 5.5 U2:

Simply take it out of maintenance mode and upgrade the remaining hosts in the cluster and don't forget about updating VMtools on all your VM's

Happy offline updating

No Health State Data after upgrade to vSphere 5.5 Update 2

I upgraded my lab environment to vSphere 5.5 Update 2 and when I logged into the Web Client I noticed that the health state information was no longer being shown.  The error I received was:

Cannot connect to the vCenter Operations server.  Check your network connection, and the running state of the virtual machines in the vCenter Operations Manager vApp

I check the vApp and network connectivity and everything was fine.  There is no firewall in-between these two hosts so I knew that wasn't the issue.  I then tried unregistering and re-registering the vCenter servers in vCenter Operations Manager by logging into the vCenter Operations Manager admin interface and un-registering and re-registering both vCenter Servers:

Once completed the vCenter Operations Appliance showed that it was unlicensed so I had to go back to vCenter and correctly license the solution again.  After a few minutes the appliance was fully licensed but still no information in the Health State.  My other vCenter which was not upgraded to 5.5 U2 works fine so I can only assume the upgrade done something with the certificates.

If anyone knows the fix for this then let me know, otherwise I'll update this post when I fix it

** UPDATE - 11/09/2014 **

I've just noticed that the option to open an object within vCenter Operations is greyed out on the vCenter that was upgraded to 5.5 U2 but not on the vCenter that's still 5.5 U1

vCenter 5.5 U1

vCenter 5.5 U2

I've also check the vCenter Managed Object Browser and both vCenter servers look to be configured identical for com.vmware.vcops so that rules out certificates.

EMEA vBrownBag Network Virtualization (VCP-NV) Series

Just a quick post to point out the EMEA vBrownBag guys are starting a series on Network Virtualization tonight to help go through the blueprint to obtain your VCP in Network Virtualization

The sessions are held every Tuesday at 19:00 and you can register via the following URL:

https://www1.gotomeeting.com/register/541316569











The schedule is currently as follows:

9/9/2014 (EMEA) VMware Certified Professional – Network Virtualization (VCP-NV) Ojbective 1 by Frank Buchsel (@fbuchsel)
9/16/2014 (EMEA) VMware Certified Professional – Network Virtualization (VCP-NV) Ojbective 2
9/23/2014 (EMEA) VMware Certified Professional – Network Virtualization (VCP-NV) Ojbective 3
9/30/2014 (EMEA) VMware Certified Professional – Network Virtualization (VCP-NV) Ojbective 4

The blueprint for VCP-NV is here and it looks like this:

Section 1 – Define VMware NSX Technology and Architecture

Objective 1.1 – Describe the Benefits of a VMware NSX Implementation
Objective 1.2 – Describe VMware NSX Architecture
Objective 1.3 – Differentiate VMware Network and Security Technologies
Objective 1.4 – Contrast Physical and Virtual Network Technologies
Objective 1.5 – Explain VMware NSX Integration with Third-Party Products and Services
Objective 1.6 – Explain VMware NSX Integration with vCloud Automation Center (vCAC)

Section 2 – Plan and Configure vSphere Networking

Objective 2.1 – Define Benefits of Running VMware NSX on Physical Network Fabrics
Objective 2.2 – Describe Physical Infrastructure Requirements for a VMware NSX Implementation

Section 3 – Configure and Manage vSphere Networking

Objective 3.1 – Configure and Manage vSphere Standard Switches (vSS)
Objective 3.2 – Configure and Manage vSphere Distributed Switches (vDS)
Objective 3.3 – Configure and Manage vSS and vDS Policies

Section 4 – Install and Upgrade VMware NSX

Objective 4.1 – Configure Environment for Network Virtualization
Objective 4.2 – Deploy VMware NSX Components
Objective 4.3 – Upgrade Existing vCNS/NSX Implementation
Objective 4.4 – Expand Transport Zone to Include New Cluster(s)

Section 5 – Configure VMware NSX Virtual Networks

Objective 5.1 – Create and Administer Logical Switches
Objective 5.2 – Configure VXLAN
Objective 5.3 – Configure and Manage Layer 2 Bridging
Objective 5.4 – Configure and Manage Logical Routers

Section 6 – Configure and Manage NSX Network Services

Objective 6.1 – Configure and Manage Logical Load Balancing
Objective 6.2 – Configure and Manage Logical Virtual Private Networks (VPN)
Objective 6.3 – Configure and Manage DHCP/DNS/NAT
Objective 6.4 – Configure and Manage Edge Services High Availability

Section 7 – Configure and Administer Network Security

Objective 7.1 – Configure and Administer Logical Firewall Services
Objective 7.2 – Configure Distributed Firewall Services
Objective 7.3 – Configure and Manage Service Composer

Section 8 – Perform Operations Tasks in a VMware NSX Environment

Objective 8.1 – Configure Roles, Permissions, and Scopes
Objective 8.2 – Describe NSX Automation
Objective 8.3 – Monitor a VMware NSX Implementation
Objective 8.4 – Perform Auditing and Compliance
Objective 8.5 – Administer Logging
Objective 8.6 – Backup and Recover Configurations

Section 9 – Troubleshoot a VMware Network Virtualization Implementation

Objective 9.1 – Identify Tools Available for Troubleshooting
Objective 9.2 – Troubleshoot Common NSX Installation/Configuration Issues
Objective 9.3 – Troubleshoot Common NSX Component Issues
Objective 9.4 – Troubleshoot Common Connectivity Issues
Objective 9.5 – Troubleshoot Common vSphere Networking Issues

See you there

Micro-Segmentation in Action

In this blog article I’m going to show you Micro-Sgementation in action with NSX in my lab.  The concept of Micro-Sgementaiton is the ability to block or limit traffic between all workloads within your datacenter, which includes blocking or limiting traffic between all VM’s on the same layer 2 network.  There is a great whitepaper here explaining more.  In my lab I have the following logical switches:

I have the following virtual machines assigned to the following logical switches:

WEB01 (192.168.0.11) -> Tenant-01-Web-Tier
WEB02 (192.168.0.12) -> Tenant-01-Web-Tier
APP01 (192.168.1.11) -> Tenant-01-App-Tier
DB01 (192.168.2.11) -> Tenant-01-DB-Tier

WEB01 can successfully ping WEB02 and vice versa:

The following rule will block all traffic from WEB01 to WEB02 but not from WEB02 to WEB01:

This was just a quick post showing the power of NSX and Micro-Segmentation.  I’m now going to start looking into the service composes functionality and policies can be applied to a specific group of VM’s.  Expect more soon 

vCOPS report to help size for vCloud Air

I was asked recently by one of my partners if there was a specific report that can be run within vCenter Operations Manager to help gather the size of an environment to then quote for some vCloud Air resources.  The best report to run to gather this information is the Virtual Machine List Report:

This will produce the following report for all VM's that vCOPS is currently monitoring:

You can also use the legacy C# client to gather this information and export to a .csv file if you prefer:

One thing to point out with the C# client is that it will show total space provisioned which will include snapshots and overhead.

Installing the NSX Management pack for vCenter Operations Manager

In this article I'm going to show you how to install the VMware vCenter Operations Management pack for NSX-vSphere 1.0.  First thing that you need to do is register for an account on the VMware Solution Exchange and download the .pak file:

Once you have it downloaded you need to upload and install it into vCenter Operations Manager.  Simply browse to the admin interface (https://UI-IP-ADDRESS/admin/) and log in, select the Update tab and browse to the downloaded .pak file and click Update.  Wait for the process to complete and you should see that it's been installed successfully:

Once the update has completed browse the customer dashboard (https://UI-IP-ADDRESS/vcops-custom) and verify that the NSX dashboards are available:

You will see the dashboard but no data will be collected until we configure the adapter instance to point to the NSX Manager as well as the vCenter associated with it.  To do this simply click Environment, Configuration and then Adapter Instances:

Add a new adapter instance of kind NSX Adapter and complete all the required information as per below:

Configure the required credentials to access NSX Manager and vCenter as per below:

Test the connection to ensure that the IP addresses and credentials are all correct:

Once completed, vCenter Operations Manager should start populating the new NSX Dashboards:

Missing logical switch in NSX GUI

I've been playing around with NSX recently in my nested lab and somehow I've managed to create a logical switch that's configured somewhere but missing form the GUI as per the screenshots below.  As you can see, my transport zone has one logical switch assigned to it:

When you go to view the logical switches it says that the list is empty:

When querying the controller VM through the CLI I can see that VNI 5002 is assigned to something:

And also when creating an NSX Edge I can see the logical switch appear there as well:

Anyone have any ideas on how to remove the logical switch via CLI as I can't seem to find any commands to do this?  I've tried rebooting both NSX Manager and the controller VM but no joy.  Once I find this out I'll update this post.

** UPDATE **

Since I can't find any way to delete this logical switch via the GUI or even CLI I thought I'd try the API.  When running the following GET command against the NSX Controller I still can't find that phantom logical switch:

GET https://10.1.2.41/api/2.0/vdn/scopes/vdnscope-3/virtualwires

As recommended by Geordy Korte (Blog | Twitter) in this VMware Communities post I tried forcing a sync via NSX Manager with no success:

I also tried rebooting the entire lab which included hosts, vCenter, NSX Manager and controllers.

** RESOLUTION **

First of all a big thanks go out to Dmitri Kalintsev (Blog | Twitter) for spending around an hour with me going through various troubleshooting techniques to get to the bottom of it.  Ultimately the issue was caused due to only having one NSX controller.  Basically I issued a delete command on the logical switch, the NSX controller deleted it from it's database and the hosts and then tried to delete it from the NSX controller which wasn't quite ready as I had just rebooted it.  If I had the recommended three controller VM's as per best practice this would not have happened.  So, how did Dmitir help me resolve this, well it's quite clever when you think about it.

First he asked me to change the controller plane of the Transport Zone from Unicast to Multicast but I first had to add Multicast IP addresses into the segment ID as per below:

I then changed the control plane to Unicast ensuring that I ticked the option to Migrate existing Logical Switches to the new control plane:

I then deleted and re-provisioned a new NSX controller and then when that was fully up and running, changed the Transport Zone back to Unicast remembering to tick the option to migrate existing logical switches and removed the multicast IP addresses from the segment ID:

Once this was performed the logical switch re-appeared:

Once again, big thanks to Dmitri and everyone else who helped out.  Hopefully this will help people who want to learn NSX and only use one NSX controller VM in their lab.