Decommission old vCenter Server 6.0 Appliance from Platform Services Controller

I deployed a temporary vCenter Server 6.0 Appliance to my existing lab to test the cross vCenter vMotion functionality across three vCenter appliances.  Once I validated this I no longer had the need for the VCSA and didn't want it taking up valuable resources in my lab.  My OCD also kicked in and I wanted to get rid of the associated error message that displayed within the web client:

As a good techie I searched for the solution but not couldnt find anything.  I posted the issue to twitter and legend William Lam (Blog | Twitter) was kind enough to post a link to a VMware KB article that explained the command:

If you've done what I've done and forgotten which VCSA was the PSC when you SSH in it should tell you at the logon screen:

After following the KB article I was able to successfully remove the decommissioned VCSA from the PSC and I no longer receive the warning within the Web Client.  I did have a slight hiccup in that the name of the VCSA in the error above was in capitals but inside the component manager database it was all lower case so the command had to be in lower case

North East VMUG - Thursday 21st May

The next North East VMUG will be held on Thursday 21st May at the Centre for Life in Newcastle:

International Centre for Life 

Marlborough Suite - Conference and Banqueting 

Times Square

Newcastle

NE1 4EP

You can register for the event here

The agenda is currently as follows:

9:30      Event Registration
10:00    Welcome & Agenda – VMUG Leadership
10:15    VMware Update – Michael Armstrong (Blog | Twitter)
11:00    vCloud Air DR (DRaaS) – Dave Hill (Blog | Twitter)
12:00    Lunch
12:30    Tegile – Gold Sponsor Presentation
13:30    Break
13:45    Data Centre Migration Project – Alan Burns
14:45    Break
15:00    Reflections on Convergence  – David Thomas
15:45    Break
16:00    EVO:RAIL – Mike Laverick (Blog | Twitter)
16:45    Closing statement and raffle
17:00    Onwards to vBeers

Big thanks to our Gold sponsor Tegile and Silver sponsor 10Zig

NSX Fundamentals Training events in May

There are some free NSX Fundamentals training in the UK planned for May by the Networking and Security Business Unit at VMware if you want to understand more around NSX.  The agenda for these events is as follows:

10:00 - Welcome & Introduction
10:15 - Overview and Architecture of VMware NSX
12:00 - Lunch
12:30 - The scalable, automated Data Centre network - Arista
13:30 - Securing the Next-Generation Data Centre - Palo Alto Networks
14:30 - Deep Security - Trend Micro
15:30 - Wrap and close

They will include plenty of white boarding and demo's and the more audience participation the better.

Current dates, locations and registration links are:

12th May - Dublin - Register here
18th May - Manchester - Register here
19th May - Edinburgh - Register here
21st May - London - Register here

I'll be presenting at the Manchester and Edinburgh events so register and I'll see you there

Nested vSphere 6.0 with VMware tools as standard

Just a quick post on something that I just noticed.  I run a lot of nested ESXi hosts in my homelab for testing as it's quicker and cheaper to stand these up instead of purchasing new hardware.  With vSphere 6.0 when you created a nested ESXi host VMware tools is automatically enabled inside the guest OS without having to install the fling

Performing a cross vCenter vMotion with vSphere 6.0

With the release of vSphere 6.0 it was time to upgrade and completely redesign the homelab.  I wanted to start testing design scenarios around NSX and having multiple vCenter servers but first thing I wanted to try was cross vCenter vMotion which is a new feature in vSphere 6.0.  There are some requirements around cross vCenter vMotion which are required:

• vCenter 6.0 and greater
• SSO Domain
• Same SSO domain to use the UI
• Different SSO domain possible if using API
• 250 Mbps network bandwitdh per vMotion operation
• L2 network connectivity on VM portgroups (IP addresses are not updated)

Within my lab I have two physical ESXi 6 hosts both running 4 nested ESXi 6 hosts each, a vCenter Server Appliance and an NSX Manager.  The four virtual ESXi 6 hosts are added to two clusters (MGMT and Compute) for both PA (Palo Alto) and NY (New York) sites.  Within the New York datacenter I have a TEST01 VM which I will migrate to the Palo Alto Datacenter.  A picture says a thousand words:

All hosts are connected to the same back end storage array so I will not be migrating the storage at the same time and I've already configure VMK ports for vMotion.  Right click on the VM and select migrate:

I'm just going to change the compute resource so ensure it's checked and click Next:

You now need to select the host that you want to migrate the VM to.  You have the option of selecting a specific Host, Cluster, Resource Pool or vApp.  In this example I'm going to move it to the PA-Compute cluster from the NY-Compute cluster.  In order for the clusters to appear I had to enable DRS and EVC on the clusters even though they had exactly the same hardware.  Once the compatibility checks succeed click next:

Select a folder on the remote vCenter to place the virtual machine in and click next:

Select the network on the remote vCenter that you want to connect the VM to.  It doesn't have to have the same portgroup name but obviously it needs to be backed by the same VLAN otherwise you'll loose network connectivity and have to re-ip the VM.  In this example I'm moving a VM from the Compute-VLAN8-NY-Servers portgroup to Compute-VLAN8-PA-Servers.  Once compatibility checks have succeeded click next:

Select the vMotion priority and click next:

Check the destination is correct and click finish and watch the magic happen:

Once the vMotion has completed the VM will now reside in the new cluster attached to the new vCenter:

One ping dropped throughout the entire process:

The task shows completed successfully and the hosts the VM was migrated from and to:

After presenting to numerous customers around what's new with vSphere 6.0 cross vCenter vMotion was definitely a welcomed feature.  So go update your environment and take advantage of all the new features.

Creating a new vMotion VMK adapter using the new vMotion IP Stack

One of the new features of vSphere 6.0 is that you can now route vMotion traffic over layer 3 networks.  You could accomplish this in previous versions by using static routes on a per host basis but it did require approval from VMware before GSS would officially support this.  Now with vSphere 6.0 this is supported out of the box.  This is accomplished by giving vMotion it's own IP stack with it's own default gateway.  I'm going to quickly show you how to create a new vMotion VMK port that utilizes the new vMotion TCP/IP stack.

First, create your VMK port as you normally would and ensure the option for VMkernel Network Adapter is checked and click Next:

Select the portgroup that you can this VMK adapter to be connected to and click Next:

Click on the TCP/IP stack option and select vMotion and click Next:

Give the VMK adapter an IP address and subnet mask.  You'll notice that you don't have the option to enter the default gateway.  We need to configure this option on the actual vMotion TCP/IP stack.  Click next once you've entered the correct IP information:

Verify your settings and click Next:

Your new VMK adapter is created but you still need to configure the default gateway for the IP stack:

Click TCP/IP configuration, select vMotion and then click the pencil to edit it:

Select the DNS option and enter your DNS server and search domain details:

Click Routing and enter your default gateway and then click OK:

The VMK adapter should now have all the correct information to start routing vMotion traffic over layer 3:

Replacing Sky's SR102 modem / router

This post is mainly for my own knowledge as with age and NSX my brain doesn't seem to retain information as good as it use to.

** Please note it is against Sky's policies to use any other router / modem apart from the one supplied **

I recently moved house and was no longer in a Virgin Media area and since I was ordering Sky television I also opted for their Sky Fibre unlimited package as well.  I'm a big fan of the MikroTik routers and switches and use a RB751G in my lab as my default router and L3 gateway and obviously wanted to continue using this in my new house.

Sky Fibre unlimited now comes with the combined modem / router called the SR102 which is adequate for home use, but not for my lab:

When researching I found that I simply couldn't replace the SR102 with a standard BT OpenReach modem as Sky use DHCP option 61 as a client authentication as per ITEF:

"
9.14. Client-identifier

This option is used by DHCP clients to specify their unique identifier.  DHCP servers use this value to index their database of address bindings.  This value is expected to be unique for all clients in an administrative domain.

Identifiers SHOULD be treated as opaque objects by DHCP servers.

The client identifier MAY consist of type-value pairs similar to the 'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist of a hardware type and hardware address. In this case the type  field SHOULD be one of the ARP hardware types defined in STD2 [22].  A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (e.g. a fully qualified domain name).  

For correct identification of clients, each client's client-identifier MUST be unique among the client-identifiers used on the subnet to which the client is attached.  Vendors and system administrators are responsible for choosing client-identifiers that meet this requirement for uniqueness.

The code for this option is 61, and its minimum length is 2.

Code   Len   Type  Client-Identifier
+-----+-----+-----+-----+-----+---
|  61 |  n  |  t1 |  i1 |  i2 | ...
+-----+-----+-----+-----+-----+---
"

So, in order to replace the SR102 with an OpenReach modem and MikroTik router you first need to obtain the username and password used to authenticate with Sky's servers.  This can be achieved by using wireshark and sniffing the DHCP discover packets when powering on the SR102.  This video shows you how to extract the username and password:

Once you have it extracted in the form of MACADDRESS@skydsl|PASSWORD i.e. (00:00:00:00:00:00@skydsl|a34sdre6) you need to convert it from ASCII to HEX using an online converter (This worked for me - http://www.asciitohex.com/)

Once you have the client identifier in HEX format you need to configure option 61 on the DHCP client of your MikroTik router.  Log into WinBox and browse to IP and then DHCP Client and in the Option 61 option enter the value as 0xHEXVALUE (You need to put 0x at the front of the value)

Once finished ensure your MikroTik is set to DHCP and not PPPoE or static and you should recieve and IP address from Sky's DHCP servers:

I also configured the WAN port of my MikroTik with the same MAC address as my SR102 as I've read a few articles that say it can potentially take a few hours for the MAC address to time out which means if you need to swap back to the SR102 you potentially have wait before connectivity will be restored.