VMware NSX – ESX for Networking

Do you still remember the first virtual machine you created? The first hypervisor-based server that you worked with? I do. And do you want to know why? Because it was such a great experience compared to all the steps that were related to setting up a physical server in the datacenter. Identifying a rack, network cabling, ordering storage capacity, labeling all cables… But before that you had to choose the appropriate (final) server hardware. What does the customer actually need? 2 or 4 sockets? How much memory? How many NICs? Because any hardware upgrade would become pretty complex. You still remember those days? I don’t want to go back…

So, where are we today? We still need to deploy servers in racks. But (at least to my observation), this process has lost it’s complexity. Besides a certain standardization of ESXi hosts and their storage and network connectivity, resource pooling and capacity management on a cluster or virtual datacenter level brought more agility to the infrastructure.

Deploying a new VM on an existing vSphere infrastructure is pretty easy. From a compute and memory perspective, there is (nearly) always an empty slot somewhere in the cluster.

For storage, the introduction of Thin Provisioning and Storage DRS have provided lots of flexibility as well. You are now able to place new VMDKs on shared datastores more efficiently. And – if necessary – there is still the option to change the size of the individual VM or to (Storage) vMotion a VM for example from it’s temporary to a production location. Elasticity, flexibility, agility – we are done, aren’t we?

We are not. One of the biggest limitations I am seeing these days is around networking. Truth is, compute and memory resources are very often fragmented by networking constraints. “This VLAN is not available in this part of the datacenter”, “the customer can only work with this VLAN/IP range”, “we don’t have Firewall capacity and need to order a new hardware appliance in this network segment”. If you hear any of these comments, it means additional complexity. And time.

Last year, VMware acquired a company called Nicira to address this “missing piece” of the Software-Defined Datacenter vision. And just a few weeks back, VMware announced “NSX” – or “ESX for Networking” as I will call it.

In VMware NSX, the very best of Nicira’s Network Virtualization Platform (NVP) and VMware’s vCloud Networking and Security will come together to virtualize the network.

Quoting the blog article:

VMware NSX exposes a complete suite of simplified logical networking elements and services including logical switches, routers, firewalls, load balancers, VPN, QoS, monitoring, and security; arranged in any topology with isolation and multi-tenancy through programmable APIs – deployed on top of any physical IP network fabric, resident with any compute hypervisor, connecting to any external network, and consumed by any cloud management platform (e.g. vCloud, OpenStack, CloudStack).

Personally, I am pretty excited about the things to come. And the day, on which I can say: I virtualized my first network

Horizon Workspace behind a DMZ loadbalancer

During the implementation of Horizon Workspace at a customer I’ve experienced a quite challenging situation last week. While the installation was a pretty straight forward process if you stick to our install guide we weren’t able to reach Horizon from outside the company network.  After typing the external web address in the browser it always went to the internal address which of course wasn’t reachable from outside. The setup was exactly our reference architecture shown in the picture below with a loadbalancer in the DMZ that points to the Horizon Gateway appliance on the internal network.

Horizon Workspace
(Source: https://www.vmware.com/files/pdf/techpaper/vmware-horizon-workspace-reference-architecture.pdf)

After some troubleshooting we found a very easy solution, but it was not that obvious or very well documented. When the OVA has been deployed you have to check the DNS resolution for all internal and external names and make sure the PTR record (reverse resolution) is working. It’s critical that no aliases for the names are configured, the reverse resolution is working fine and no other records (MX,etc.) are configured. Now comes the important part: while completing the console-based configurator menu after starting the vApp it’s absolutely important to enter – when asked by the wizard – the EXTERNAL name, i.e. horizon.yourcompany.com as the Horizon FQDN and NOT the internal name, i.e. horizon.justforinternal.local. In other words enter the name which points to the loadbalancer and not the name of the Horizon gateway-ca.

Once that configuration was done, it worked like a charm!