There’s an ever growing variety of NSX flavours as VMware expands the range of their Network Virtualisation and security platforms. A recent podcast highlighted these to me, and I thought it worth summarising here in a quick post.
NSX DataCenter– This is the product that people have usually previously referred to as NSX (the NSX moniker now applying to the whole suite of products). This has two varieties: NSX-V which is the traditional Network Virtualisation for vSphere and NSX-T which is the Network Virtualisation product for multi-hypervisor and multi-cloud platforms. The current NSX-T version 2.2 itself has two options- the datacentre release for multi-hypervisor support (Ubuntu and Red Hat KVM platforms) or an offering with additional cloud support NSX-Cloud (currently for the Microsoft Azure platform).
NSX SD-Wan By VeloCloud is from the recent Velocloud aquisition by VMware providing, as the name suggests, software-defined Wide-Area-Network capabilities.
NSX Hybrid Connect was formerly known as HCX (Hybrid Cloud Extension) and was announced at VMWorld Europe 2017. This is the VMware platform for consolidating datacentres and moving workloads around- aiming for an “any platform to any platform” style of seamless vMotion.
For more info, check out the VMware Community Podcast episode #438 with Tim Davis (from about 9 minutes).
I’m using vSphere Replication to replicate a number of VMs to a datastore which is being decommissioned. I can’t reconfigure replication by code (I’ve mentioned that there’s no public API or PowerCLI around the vSphere Replication functionality in vSphere 6.5 before- most recently on Twitter) and I can’t multi-select VMs in the vSphere Web Client and reconfigure en-mass through the GUI.
There’s also no way of telling which VMs are being replicated to this datastore without going into the reconfigure dialogues for each one individually. That’s a lot of clicking before even starting to update the configuration.
I’ve put together a PowerCLI function takes a little of this pain away by establishing which folders on a given datastore contain VMDK files. I’ve already migrated any Virtual Machines off so any remaining VMDKs on the volume should be associated with a replication process. Additionally in this case the default folder name was used when setting up the replication so all the folder names correspond to a VM.
The function is called “Get-VmdkFolders” (as there’s potentially other uses for it) and is available on GitHub here. With this I now have a list of VMs that need manually reconfiguring.
PS C:\> Get-VmdkFolders "MyReplicationDatastore"
Registration for VMworld 2018 opened this week (8th May) with Early-Bird discounts available until 15th June for the US event, or 27th July for the European event. This gives prospective attendees a $300 / €200 discount on the regular price which runs up until the day before the respective events. This year VMworld US will again be in Las Vegas at the end of August, with the European leg staying in Barcelona but moving to early November.
I’ve seen no official word on why the EMEA event has moved down the calendar, but this does put it in a different financial quarter to the US event both for VMware and their partners. This should allow for more flexibility with both product releases and marketing budget through the year, especially when combined with the recent partner “Empower” event and Dell Technologies World both sat in the spring.
Full details of the event, along with the registration details are available at vmworld.com. The site features a link at the top of the page to choose between the Las Vegas and Barcelona events.
vSAN licenses are assigned per-cluster, so whilst the total number of vSAN licenses in a vCenter inventory might match the total number of vSAN host CPUs, they may not be assigned correctly to the clusters. This will trigger the critical vCenter alarm “License inventory monitoring”. This will also occur if a cluster is expanded (e.g. additional hosts and vSAN licenses are purchased) as it’s only possible to assign one license key to each cluster.
In the example screenshot here we have 2 vSAN license keys, each valid for 8 CPU. The total 16 CPU capacity matches the 16 CPU in use. However, one cluster has 10 CPUs (i.e. 5 dual socket hosts) and the other only 6 CPU. Therefore one license key is 2 CPU oversubscribed whilst the other has 2 free.
The method to resolve this is to use the MyVMware license portal to split and merge your pool of vSAN licenses until you have license keys where the capacities match your cluster sizes, and then re-license the vSAN environment. This VMware KB article explains in detail how to do this divide, and merging is a similar process on the same interface: https://kb.vmware.com/s/article/2006972
In the example screenshot above, this was a case of splitting one of the 8 CPUs into a 6 and a 2, and then merging that 2 with the remaining 8 CPU key to create a 10 CPU key and a 6 CPU key which matched the cluster sizes. The old 8-CPU key that was split was removed from the license inventory.