Infrastructure | Breek Een Been

Nested NSX Upgrading Nsx 6.0.5 to 6.1.2

Wed, 07 Jan 2015 18:59:02 +0200

In earlier blogposts I described how I build my nested NSX lab. This environment was based on NSX version 6.0.5 and in this post I will briefly show you how you can easily upgrade your NSX environment, in this case we will upgrade to version 6.1.2. Luckily the documentation of VMware is up-to-date which should make this proces pretty easy. Let’s start with the NSX Manager. NSX-Manager Before we actually start, make sure your filename of the upgrade bundle ends with tar.gz, otherwise the upload will fail. I had to rename the file; from: VMware-NSX-Manager-upgrade-bundle-6.1.2-2318232.tar _to: VMware-NSX-Manager-upgrade-bundle-6.1.2-2318232.tar.gz

In the upgrade page, you’ll find another upgrade button in the top right corner, click it and in the new screen, select the upgrade file.

After choosing the right file, click continue, now you have to wait, while the file is being uploaded.

If everything wen well, you should see a screen confirming the upgrade from 6.0.5 to 6.1.2 and a question about enabling SSH. I enabled SSH and clicked upgrade.

After the upgrade you will be redirected to the login page, login and check the version number in the upper right corner.

NSX Controllers

The next step is to upgrade the controllers, log in to the vSphere webclient and go to Networking & Security and click the Installation option on the left side. Make sure the Management tab is selected and you should see on the right side “Upgrade Available”, click it and click yes, that you are willing to upgrade the controllers.

In the screen below the manager, you see that the controller is being upgraded.

If everything went fine, the upgrade status column should dissappear and the new version is displayed, also the upgade available link in the upper rigt corner should be gone.

Host upgrade

Go to the “Host Preparation” tab and you should see that there is an update available.

Click update near the host that you want to upgrade. The host is getting upgraded and will be rebooted when the installation is done. However if you have just one host in the cluster, like in my lab environment, this will need some manual interaction. This is because VMware has no other hosts where the workload can be migrated to.

Go to host & clusters and you will see, that the host need a reboot.

I simply shut down the VM and rebooted the host, I started with the one in the compute cluster. For the upgrade of the host in the management cluster I temporarily moved the compute host to this cluster and let it run the NSX Manager, till the second host was also upgraded. These steps took me a while. I also increased the memory of the NSX Manager to 6GB it seems the upgrade made it a bit slower. If everything went well you should see this eventually.

NSX Edge upgrade

The last part of this upgrade is the NSX Edges, this means the distributed router and the edge. As mentioned in earlier posts in my opinion the distributed router should gets his own section. Click the appliance you would like to upgrade, order doesn’t matter and select from the action menu “Upgrade Version”.

It is nice to notice, that the upgrade of the Edge is an actual new installation;

This is it, when all the NSX Edge devices (including the distributed router(s)) are up-to-date the upgrade is doen. As you can see upgrading a NSX environment consist just of a few basic steps, the only challenging step is the host-preparation, but that is due the lack of resources in my lab set-up. In production this would be easier.

Nested Nsx Vmware Nsx on Intel Nuc Lab Setup Part 3

Mon, 29 Dec 2014 09:37:17 +0200

In the previous two posts I described how to set-up a nested ESXi environment on the Intel NUC and how to install and configure it for NSX. So in this post I assume everything is installed and configured and we can actually start deploying a network.

Logical Switch

If not already, go to “Network & Security” and click on “Logical Switches”, click the green plus sign, to add a Logical Switch. I used the following settings:

Name: App-Tier
Description: Application Tier
Zone: LAB-Zone

This is it, we have created a working logical switch, however to see if it actually can switch, we need to put some workload on it. To show that the communication within the Logical Switch is completely independent of the underlying network, I put the two VMs on this switch, within a completely different subnet than already used.

IP1: 172.20.20.2/24
IP2: 172.20.20.3/24

We are going to deploy two VMs I used Debian for this, but you are free to use whatever you want, as long as it can do IP. This is what I configured:

Name: App-VM1 / App-VM2
OS: Debian 7 - 64bit
vCPU: 1
MEM: 512MB Ram
IP: 172.20.20.2 / 172.20.20.3
Subnet: 255.255.255.0
GW: 172.20.20.1

Make sure you deploy a VM on ESX01 and one on ESX02, also connect them for now to the pgCompute1 and pgManagement port-group.

When both VMs are deployed, go to “Logical Switches” and click on “Add VM”, select the two VMs, select both the NICs and finish the task.

Configure the VMs with the appropriate network settings and do a ping test to each other. If everything went well, you should get a reply.

Before we continue it is nice to take a look at the controller, to see what information is stored here and get an idea how the actual traffic flow is working. You can log-in to the controller with SSH and username “admin” and the password specified earlier. With the following two commands you can list the VTEP interfaces and the MAC-addresses. The number 5000 is the segment ID (VNI = Virtual Network Identifier) assigned to the logical switch. Which can be found in the webinterface under Logical Switches.

nvp-controller # show control-cluster logical-switches vtep-table 5000
VNI      IP              Segment         MAC               Connection-ID
5000     192.168.5.11    192.168.5.0     00:50:56:62:a3:86 2
5000     192.168.5.10    192.168.5.0     00:50:56:66:dd:df 7

nvp-controller # show control-cluster logical-switches mac-table 5000
VNI      MAC               VTEP-IP         Connection-ID
5000     00:50:56:99:d0:77 192.168.5.11    2
5000     00:50:56:99:6b:d9 192.168.5.10    7

In my case the MAC addresses of the VM’s are.

App-VM1: 00:50:56:99:6B:D9
App-VM2: 00:50:56:99:D0:77

You could also use the following command, to see the ARP table, remember this like normal switches has a time-out, so when it is empty initiate a ping or some other traffic.

nvp-controller # show control-cluster logical-switches arp-table 5000
VNI      IP              MAC               Connection-ID
5000     172.20.20.3     00:50:56:99:d0:77 2
5000     172.20.20.2     00:50:56:99:6b:d9 7

As you can see in the mac-table, there is a relationship between the MAC address and the VTEP-IP. What it actually says is that if App-VM1 sends something to App-VM2, the traffic will be encapsulated (VXLAN-header), with the destination IP (192.168.5.11) of the VTEP connected to the host running the VM. After the host received the traffic, it is being decapsulated and sent to the VM, so the VM’s don’t know anything about how the traffic is handled and won’t see any difference between a virtualized or a traditional network.

Distributed Router

Another neat feature of NSX is the distributed router, this not only means you can route traffic, but the neat thing about it is, that this can be done on “host”-level. This means that when two VMs are running on the same host, but in different subnets, the distributed router (remember installed VIB) will route the traffic in the kernel, so the traffic won’t have to leave the host! To create a distributed router, go to “Network & Security” and click on “NSX Edges”. (If you ask me, they should make two categories, “NSX Edges” & “Logical Routing”, this would make a in my opinion lot more sense) Click the green plus sign and select logical distributed router.

Next specify a password and Enable SSH acces.

Specify the “Management_and_Edge” cluster.

Connect the management interface to the “pgManagement” port-group and specify an IP, in my case 10.10.11.126.

Add an interface and connect it to the “Logical Switch” - “App-Tier” and specify an interface, in this case 172.20.20.1 [!

When done with step 4 it should look as follow.

We can skip the HA configuration and continue, when satisfied with the settings, click Finish.

The first thing we want to do is enable routing between two logical switches. Therefore go to Logical Switches and create a second one, named: “Web-Tier”.

Deploy (or clone) a new VM and connect it to this “Logical Switch”.

Name: Web-VM1
OS: Debian 7 - 64bit
vCPU: 1
MEM: 512MB Ram
IP: 172.20.10.2
Subnet: 255.255.255.0
GW: 172.20.10.1
Cluster: Compute

Since we didn’t connect the distributed router to the Web-Tier Logical Switch, there is no gateway and no communication possible between the App- & the Web-Tier. The App-Tier is connected and you can try ping the gateway 172.20.20.1 from one of the App-VMs, this should work. Go back to NSX Edges en open the distributed router we created, select the Manage tab, click on Settings and select interfaces. Now click the green plus sign and add the Web-Tier and create an interface with IP 172.20.10.1.

Before you click OK, open the console of the Web-VM1 and start a ping to one of the App-VMs, now click OK. Immediately after the configuration, you should get a response on the pings.

It is important to know that the logical router instance (VM) is in this example purely for configuration of the distributed router and that traffic won’t go through it. When sending traffic to App-VM1 which is on the same host, the traffic won’t leave the host, but is routed at the kernel. If traffic is send to App-VM2, the traffic is routed on the host of the Web-VM1 and send (on the App-Tier Logical Switch) to the other host, like it was L2 switching. The last part of this post is bringing data outside the virtual world, there are two ways of accomplish this. The first one is bridging and the second one is routing. I won’t go further into bridging, but what it simply said does is, connecting a VXLAN to a VLAN.

Edge Services Gateway

Best practice is that we use an Edge Services Gateway (ESG) for connection with the outside world. This means that the Logical Router will forward the traffic to the ESG and the ESG will route the traffic to the physical world. This is just one of the many functions the ESG can do, it can also NAT, Loadbalancing, basic firewalling, etc. VMware likes to call it a “swiss army knife” due the roles it can fulfill. Between the Logical Router and the ESG we will have a so called transit network, for this create a new Logical Switch and name it Transit.

My uplink is in a different VLAN, so I created a new portgroup pgUplink, but if your network is flat or you want to (mis)use the management port-group, this is no problem. Make sure, when you create an additional port-group, do this at the Management and Edge (cluster) Distributed Switch.

Go back to the NSX Edges and click the green plus sign, similar to the deployment of a Logical Router, however now we choose Edge Services Gateway.

Fill in the credentials and select the Management and Edge Cluster for deployment. A Compact deployment for this LAB is sufficient.

Now the most important part, create the interfaces. Chooste “internally” for the Transit. I will use 172.16.10.0/24 as transit subnet and the Edge will get .1 and the Logical Router (later on) .2. In the Uplink subnet I have 10.0.0.0/24 and will use 10.0.0.1 for the Edge. My physical router has 10.0.0.254, so this will become my default gateway.

Leave all the further settings default and finish the wizard.

Now open the just deployed ESG and go Manage, Routing, (for now) we will create static routes to the Logical Router we created earlier. Add the following two routes for the App and Web tier, by clicking on the green plus sign.

172.20.10.0/24 - 172.16.10.2
172.20.20.0/24 - 172.16.10.2

If you added both routes, click on Publish Changes.

The next step is to add the 172.16.10.2 interface to the Logical Router, and set the default gateway for the Logical Router to the ESG. Open up the settings page for the Logical Router and add the interface.

Go to routing and set the default gateway under Global Configuration to the ESG, make sure to Publish Changes when you are done.

Now almost everything is set, however when you will test to communicate with the outside world, you will see that it will fail, there are two more (small) steps to take. First, make sure the outside world, your router or cliënt has a route to the new Web and App subnets. I first tested it of my desktop client, which has an IP in 10.0.0.0/24. I added a specific route to the WebVM.

172.20.10.2/32 - 10.0.0.1

Now the very last step is to check the firewall of the ESG, by default it only has a rule which accept traffic, which has a source VSE (I assume this stands for vShield Edge). For this lab we will add a rule, which allows any traffic. Go to the ESG and click on firewalling and click the green plus sign. It will by default create a rule which accepts any, any, any :). Don’t forget to publish the new rule.

Now you can test and everything should work! Now we have set-up a very basic and simple lab environment which runs NSX pretty well. Even despite the limited resources, the Intel NUC has proven itself to be capable of handling the load and give a decent lab experience. I think this lab is a very good starting point for further testing and learning with NSX and probably some more posts will follow concerning NSX configuration, for me it will hopefully help to eventually get my VCIX-NV. I hope you had fun and please let me know if you have any further questions, ideas or suggestions.

Nested Nsx Vmware Nsx on Intel Nuc Lab Setup Part 2

Sat, 27 Dec 2014 09:20:49 +0200

In my previous post I described how to create a nested ESXi environment, connected to a vCenter, this as a preparation to run eventually NSX. In this post we will build further on the basic set-up we created in part 1 of this series. At the end of this post we will have the NSX installed and the network prepared for all the cool things NSX can do.

Distributed Switch

Since the NSX vSwitch is based on the “distributed switch”, this is what we are going to create first on the two clusters. We will make two distributed switches, named;

dsMgmtEdge
dsCompute1

Go to your (LAB) vCenter and go to the networking tab, right click on the Datacenter and click on “New Ditributed Switch”, for now the following options are sufficient.

Number of uplinks: 1
Network I/O control: Enabled
Default port group: Create a default port group
Port group name: pgManagement / pgCompute1

Before we can actually add hosts to the distributed switches we created, we need to add the VLAN tag to the newly created port-groups. Therefore select the distributed switch, choose the manage tab and make sure settings is selected. Select the port-group and click edit settings. Under the VLAN settings, choose VLAN and enter the appropriate VLAN ID. (if you don’t work with VLANs you can skip this step)

Now we have created the distributed switch and configured the port-group, we need to add the hosts to it. Right click on the distributed switch and click on “Add and Manage Hosts”, we want to add the host, select the appropriate host.

Make sure both the “Manage physical adapters” and “Manage VMkernel adapters” are both checked. We will move the vmnic0 to the uplink of the distributed switch.

Also move the VMkernel adater (vmk0) to the new port group.

If you screw this up, it is pretty easy to start over by accessing the console of the ESXi and in the settings, choose “Network Restore Options”.

NSX Manager

Finally we can start with some real NSX stuff. The first step is the installation of the NSX Manager. Go to hosts and clusters, right click the “Management & Edge” cluster and choose deploy OVF. Point to the NSX Manager OVA. Select Accept extra configuration options.

Read & accept the EULA, pick a name (i.e. LAB NSX Manager). At the Network setup make sure you choose the new “pgManagement” port-group. At the “Customize template”, set some passwords and make the network configuration.

VSMgmt: pgManagement
Hostname: LABNSXManager
Network 1 IPv4: 10.10.11.111
Network 1 Netmask: 255.255.255.0
Default IPv4 Gateway: 10.10.11.1
DNS server list: 10.10.11.3, 8.8.8.8
Enable SSH: checked

The settings I didn’t mentioned I left blank.

Click finish and have a bit of patience. Before we can power up the NSX manager we need to do something about the resources which are by default quite heavy and we simply have not that many resources available on our LAB set-up. Edit the VM hardware settings with the following values.

CPU: 2 (instead of 4)
Memory: 4GB (instead of 12)
Memory reservation: 0 (instead of 3GB)

Power up the NSX manager and if everything went well, you will be able to visit the NSX page with a few minutes, https://IPAddress and you can log in with the username “admin” and the password specified during the deployment.

Before we continue, I noticed that the resources are a bit short, cause after 17 minutes, the NSX Mangement Services wasn’t started and it would eventually turn out to take 19 minutes. As you can see the Memory is in full use and also on the ESXi host we can see this, this is an indication that we need to increase the memory of the ESX02 (the host of the Management & Edge) cluster. Cause it is also going to run the NSX Controller(s). Luckily this is a virtual ESX host, so extending the memory is quite easy, I doubled it at this moment to 8GB. I didn’t increase the memory of the NSX Manager, since this is a LAB, I don’t care if the start-up takes a while, as long it will run fluent enough to do some testing.

vCenter integration

NSX has a tight integration with vCenter, at this moment it is an 1 on 1 relationship, which means for every vCenter, you need one NSX Manager. Log in to your just deployed NSX Manager and click on “Manage vCenter registration”, click on edit and enter your vCenter information.

After clicking ok, trust the certificate and within a few seconds it should say that is is successfully connected.

Now we are going back to our vCenter, if you are already logged in, log out and log in again. The first time it can take a few minutes, cause it will configure itself for NSX. If everything went fine you should see a new option in the menu on the left, named “Networking & Security”.

Prepare the hosts

The next step is to prepare the host, NSX will install a couple of VIB’s into the hosts, knowing;

Logical Routing
Distributed Firewall
VXLAN

Click on the new “Networking & Security” option and go to “installation”, click the “host preparation” tab. It will show the clusters available within the vCenter.

Click the install link in the column “Installation Status”, do this for both clusters. After the installation it should say “ready” on the particular host and the version for the cluster.

Controller

Now that the hosts are ready we can start deploying the controller(s), normally you would deploy at least 3 controllers, but in this LAB we will start with just one, mainly due resource restrictions. The controller is the control plane of the environment and will keep three primary tables.

ARP table
MAC table
VTEP table

Go back to the “Management” tab of the “Installation” settings and click on the green plus sign, below NSX Controller Nodes. Fill in the following.

NSX Manager: 10.10.11.111
Datacenter: Datacenter
Cluster: Management_and_Edge
Datastore: NAS
Host: 10.10.11.102
Connected to: pgManagement (select distributed switch)
IP Pool: ClusterIPPool - Create one
- Name: ClusterIPPool
- Gateway: 10.10.11.1
- Prefix Length: 24
- Primary DNS: 10.10.11.3 -> Your own DNS server
- Secondary DNS: 8.8.8.8
- Static IP Pool: 10.10.11.120 - 10.10.11.125

Password: Pick Something

Click OK, it will start deploying a controller and this can take a while.

VXLAN

The last step in the preparation of the NSX environment is the VXLAN preparation, VXLAN is the tunnel protocol which makes sure every host participating in the NSX environment is able to communicate with each other. First we going to create an IP pool, with the IP adresses for the VMKernel adapters serving the VTEP (VXLan Tunnel End Point). Therefore click in the left bar on NSX Managers and select “10.10.11.111”, make sure the “Manage” tab is selected and click on “Grouping Objects”, select IP-Pools and click on the green plus sign. To show that communication between the hosts is really independent of the underlying network, I created a separate subnet without a default gateway (although specified).

Name: VXLAN-VTEP
Gateway: 192.168.5.1
Prefix Length: 24
Static IP Pool: 192.168.5.10-192.168.5.20

Now go back to the installation, “Host Preparation” tab and in the column VXLAN click “configure”.

Leave everything default except:

VLAN: 5
IP Addressing: Use IP Pool
IP Pool: VXLAN-VTEP

Click ok and wait a few seconds, although it could give an error (didn’t find out why yet), the error will dissappear after a refresh.

If you go to the distributed switch of one of the cluster you should see something as follows:

Now we need to specify the VXLAN segment ID’s, therefore go to the “Logical Network Preparation” tab in the installation settings, select “Segment ID” and click edit. Fill in the following segment ID pool, which should be more than enough for this lab environment.

Segment ID Pool: 5000 - 5999

We don’t have to enable multicast, since we are running on ESXi 5.5 hosts.

The last part is to create a “Transport Zone”, this will tell NSX which clusters are able to communicate with each other. Click on “Transport Zones” and click the green plus sign.

Name: LAB-Zone
Control Plane Mode: Unicast
Clusters: Select both

Now we have everything prepared to do some actual networking with NSX. This is what we will be doing in my next blog post.

Nested Nsx Vmware Nsx on Intel Nuc Lab Setup Part 1

Wed, 17 Dec 2014 08:52:50 +0200

While the VMware Hands-on Labs are extremely cool and useful, I found it always very learning-full and nonetheless fun to build my own labs. To keep it fun and keep down the noise and powering costs I decided to buy some Intel NUCs, which have a good price tag and are very low on energy. Last couple of months I’m very interested in VMware NSX and it is time to try-out running this in my own Lab and on one Intel NUC, which means not much resources but I’m wondering if it can be done and hopefully work well enough to play around. In the next coming posts I will show you the steps I take to get things working, so you can follow me on this journey. This first part will concentrate on how to get the nested environment up & running. One of the biggest downsides of the Intel NUC is that it only has one NIC, which makes it difficult to run all needed parts and another caveat is that chances are that you will lock-out yourself. Luckily ESXi can run itself, we call this a nested environment. Below you see a very abstract picture about the set-up we are going to create. As you can see I choose to let the nested ESXi servers interact directly with my NAS (Synology), mainly to save resources and time. If you want a complete nested and virtualized environment including storage you are of course free to do so.

Nested NSX abstract

The blue components are the more physical parts of this environment and the actual lab is more located at the green components. I assume you have already running ESXi on your Intel NUC (or other system), if not below two good links to get you started.

When you have ESXi running on your NUC, we can create a nested environment on it. I will start small, cause I have no idea, how the NUC will handle the load and it will be easy to add another node in the feature (also a good test case). How to create nested ESXi servers isn’t new, but I will cover shortly how I’ve done it. A small note lots of older blogpost write about the vhv.enable feature, this isn’t necessary in ESXi 5.5 cause it will be set to true by default.

Network

This has nothing to do with NSX yet, but it will enable our nested hosts to communicate with the outside world. We are going to create a TRUNK port-group, so that we can use in the future different VLANs to segment the traffic, this however requieres that the connected physical switch also supports VLANs. Don’t worry if not, than this all will probably still work, however I didn’t tested it. Go to the host, networking configuration and add a port-group, with the following settings.

VLAN ID: ALL (4095)
Security - Promiscuous mode: Override Accept
Security - MAC address changes: Override Accept (optional)
Security - Forged transmits: Override Accept

Nested ESXi servers

Deploy a new VM, I have my ESXi connected to a vCenter environment, this is not the vCenter we will discuss later and is running on another NUC. So I will use the web interface. The steps taken can also be done on the traditional GUI, the only difference will be the HW version, 10 for the WUI and 8 for the GUI. Use the following settings:

Pick a VM name, for the sake of simplicity I use “ESX01” and “ESX02”
OS Family: Other
OS Version: Other (64 bit)
CPU: 4 (I started of with 2, but quickly changed to 4, needed for some componentens (i.e. Controllers))
CPU - Harware virtualization: Enable
MEM: 4 GB (enough to get started) (In part 2 I increased the memory of the ESX02 to 8GB)
HD: 1GB
Network: Trunk port-group (1 nic is enough to get started)
CD: Mount the ESXi installer

Now we created the VM, we can boot it up and start the installation, which is really a next, next finish job. When the installation is done, this can take a several minutes we start configuring the host. Open the console and press F2 and after entering your password go to “Configuring Management Network”. If you have a trunk port, don’t forget to enter the VLAN ID. Give the host an IP address, subnet, gateway and optionally for now some DNS settings. For me the IP’s are.

ESX01 IP: 10.10.11.101/24
ESX02 IP: 10.10.11.102/24
Gateway: 10.10.11.1

Since this is a lab environment I will enable the SSH console, you can do this under “Troubleshooting Options”.

Before you exit the console test if you can reach the host, a simple ping test would be sufficient. The last thing we will need to do for now on the new hosts is adding the storage. For me this is a simple NFS share on mine Synology. Go to the host, storage configuration and add the NFS storage.

Before continuing, make sure both hosts are deployed, have storage and are reachable.

vCenter

The last part of this post is about deploying the vCenter appliance, which is sufficient, for running NSX. Deploy the vCenter 5.5 OVF, I used the following settings.

Name: LAB-vCenter
IP: 10.10.11.110/24
GW: 10.10.11.1

(Since the last Chrome update, the vCenter plugin is broken, didn’t fixed it yet)

After the OVF is deployed I decreased the memory to 4GB, which is in my experience enough for a fluent experience in a LAB environment. Start the vCenter VM, as you can see on the console, you should be able to access the initial configuration on https://IPAddress:5480 and login with the default username “root” and password “vmware”.

After logging in, accept the license (of course first read it). I choose for “configure with default settings”, after clicking next and start, it will configure itself, but this will take a while. When the configuration is done, the last change I make on the configuration is that the password of the admin will not expire.

Now we are done we can actuale access the vCenter interface by going to https://IPaddress:9443/vsphere-client

We don’t worry about license keys for now, so you can simply ignore this message or close it by clicking the cross sign on the right. Go to vCenter and click on hosts and clusters. Now we start by creating a new Datacenter. Click on “Create datacenter” and if you want give it a name, you can also leave it default “Datacenter " and click ok. Now we are going to create two clusters, called;

Management_and_Edge
Compute

Click on create cluster and give it the desired name, we can leave HA and DRS off. You can create the second cluster by right clicking on the Datacenter. When both clusters are created we need to add the ESX hosts to the appropriate cluster. We add ESX02 to the Managment & Edge cluster and the ESX01 to the Compute cluster.

Right click on the cluster and select “Add Host”. Fill in the IP of the host, on the next page the username and password of that specific Host, leave the other settings default.

Do this for both hosts, when you have done this, your environment should look as follow.

For now we are done, we have setup a basic nested environment on which we will go install and configure NSX. When you are bored and can’t wait for the next post or just want to optimize your environment, consider the following actions, these are all optional and not necessary to install NSX, also these steps can be taken on a later time.

Optional but nice!

Enable Nfs Vaai on a Synology X10

Thu, 04 Dec 2014 09:12:53 +0200

I was really trilled when Synology announced also releasing DSM 5.1 for their x10 series. Why? This because DSM 5.1 has a great feature called NFS for VAAI. In simple words, hardware acceleration on your NAS. For everyone using a Synology with at least DSM 5.1 or later and have VMware vSphere connected to it, I really would recommend enabling this feature. How you can do this, is explained below. First check your vSphere storage configuration, without VAAI you will see, that hardware acceleration is not supported.

NFS VAAI not supported

Now first download the VAAI plugin, cause VMware needs to know how it can offload the storage tasks to the Synology NAS. The plugin can be found here. When the download is finished, save the file somewhere on the NAS where VMware can also access it, for me it is a folder named __Management under the NFS share.

Connect to your vSphere host using SSH, make sure you have enabled SSH. (host - configuration - security profile, enabled & start SSH) When you are logged in, you can install the plugin with the following command.

esxcli software vib install -d /vmfs/volumes/Gimli\ \\(1\\)/\_\_Management/Updates/SYN-ESX-5.5.0-NasVAAIPlugin-1.0-offline\_bundle-2092790.zip

Wait a few seconds, it can take a few minutes, if everything went fine, you should see the following message.

Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: Synology\_bootbank\_esx-nfsplugin_1.0-1
   VIBs Removed:
   VIBs Skipped:

You can reboot the system from here, simply with the command “reboot” or from the client. After the reboot the configuration page should say hardware acceleration: supported.

NFS VAAI supported

Bind DNS Server in Homelab With Split View

Tue, 23 Sep 2014 19:54:11 +0200

One of the most undervalued infrastructure components in my opinion is DNS. A lot of services / components rely upon DNS and if DNS is mis-configured, not available, slow function or somehting else doing that shouldn’t be happening, it can lead to performance and other strange problems. In my homelab I’m running BIND DNS. One of the main reasons I choose BIND is the option to use Views. Views are making sure if I’m internally connected (e.g. WiFi @ Home) I get an internel IP as a response and if I’m externally connected, I get my public IP as response. My installation is based upon Debian 7, I won’t go into much details about this installation, since it is pretty straight forward. Make sure you use an static IP, don’t set your DNS to the server IP yet :) and I prefer to only install SSH, so I can start with a nice clean machine. First let’s install the BIND packages.

aptitude install bind9

Al the configuration files are stored in /etc/bind, so let’s go to this directory and start with creating a forwarder, so all DNS request can go through this DNS server. We will protect this forwarder by an ACL, so only internal cliënts can use this DNS server for relaying.

cd /etc/bind
nano named.conf.options

At the top of this file, before options, create the ACL, I use RFC1918, cause my subnets will vary a lot in my lab.

acl "trusted" {
        192.168.0.0/16;
        172.16.0.0/12;
        10.0.0.0/8;
        localhost;
        localnets;
};

In this example localnets, isn’t necessary assuming the server is already part of one the above listed subnets. Next we will add the lines, which enables the forwarding, these should be placed within the options placeholder.

forwarders {
       8.8.8.8;
       8.8.4.4;
};

allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };

That’s it for the forwarding. Now let’s create our own domain. First let’s disable the default configuration.

nano named.conf

and comment the line include “/etc/bind/named.conf.default-zones”;

//include "/etc/bind/named.conf.default-zones";

Open up named.conf.local

nano named.conf.local

and add the following lines.

view "local" {
        match-clients {10/8; 172.16/12; 192.168/16;};
        zone "lab.breekeenbeen.nl" {
                type master;
                file "/etc/bind/zones/lab.breekeenbeen.nl.local";
        };

        zone "11.10.10.in-addr.arpa" {
                type master;
                file "/etc/bind/zones/rev.11.10.10.in-addr.arpa";
        };

};

Here we declare a view, which will only listen to RFC1918 (local) addresses, we than create two different zones, one for forward look-ups and second for reverse look-ups. In his case the domain/zone is “lab.breekeenbeen.nl” and the IP range for the reverse look-up is 10.10.11.*. As you can see, we are pointing to two different files, these files will actually contain the hostnames. So let’s create and edit them. I added the .local for recognitizion that it will contain local addresses.

mkdir zones
touch zones/lab.breekeenbeen.nl.local
touch zones/rev.11.10.10.in-addr.arpa

Let’s start with the forward look-up table.

nano zones/lab.breekeenbeen.nl.local

$TTL 3D
@       IN      SOA     ns1.lab.breekeenbeen.nl. root.localhost(
        2014092201      ; serial number
        28800           ; refresh (i.e. 3h)
        3600            ; retry (i.e. 15M)
        604800          ; expire (i.e. 3W12h)
        38400           ; minimum (i.e. 2h20M)
);

@                       IN      NS      ns1.lab.breekeenbeen.nl.

dnsserver               IN      A       10.10.11.3;
ns1                     IN      A       10.10.11.3;

The above sample is pretty basic, remember everytime you make changes and commit them, you need to change the serial number, I use year-month-date-follow-up as a serialnumber. Every host can be added on a new line, here is one host “dnsserver” which will result in IP 10.10.11.3, the FQDN of this host is dnsserver.lab.breekeenbeen.nl. Restart the DNS server and check if it works with nslookup.

root@dnsserver:/etc/bind# nslookup
> server 10.10.11.3
Default server: 10.10.11.3
Address: 10.10.11.3#53
> dnsserver
Server:         10.10.11.3
Address:        10.10.11.3#53

Name:   dnsserver.lab.breekeenbeen.nl
Address: 10.10.11.3

If it doesn’t work, you can check on errors in the syslog.

tail /var/log/syslog

That’s it, now the last thing to configure is the reverse look-up.

nano zones/rev.11.10.10.in-addr.arpa

$TTL 3D
@       IN      SOA     ns1.lab.breekeenbeen.nl. root.localhost(
        2014092201      ; serial number
        28800           ; refresh (i.e. 3h)
        3600            ; retry (i.e. 15M)
        604800          ; expire (i.e. 3W12h)
        38400           ; minimum (i.e. 2h20M)
);

                        IN      NS      ns1.lab.breekeenbeen.nl.

3                       IN      PTR     dnsserver.lab.breekeenbeen.nl.

Restart the DNS server and check if the reverse look-up works.

root@dnsserver:/etc/bind# nslookup
> server 10.10.11.3
Default server: 10.10.11.3
Address: 10.10.11.3#53
> set type=PTR
> 10.10.11.3
Server:         10.10.11.3
Address:        10.10.11.3#53

3.11.10.10.in-addr.arpa name = dnsserver.lab.breekeenbeen.nl.

Now we can do exactly the same for the external look-ups. We just add another view for the external requests.

nano named.conf.local

view "external" {
        match-clients { any; };

        zone "lab.breekeenbeen.nl" {
                type master;
                file "/etc/bind/zones/lab.breekeenbeen.nl.external";
        };
};

It depends on your configuration if you need/want a reverse lookup for external requests. If you run an e-mail server for example it would be wise to set-up a reverse lookup zone. For now I leave the reverse look-up out of it, but it is exactly the same as described above. Like we did for internal, we create the external look-up file and fill it with the appropriate configuration. To speed things up, we just copy the file.

cp zones/lab.breekeenbeen.nl.local zones/lab.breekeenbeen.nl.external
nano zones/lab.breekeenbeen.nl.external

$TTL 3D
@       IN      SOA     ns1.lab.breekeenbeen.nl. root.localhost(
        2014092201      ; serial number
        28800           ; refresh (i.e. 3h)
        3600            ; retry (i.e. 15M)
        604800          ; expire (i.e. 3W12h)
        38400           ; minimum (i.e. 2h20M)
);

@                       IN      NS      ns1.lab.breekeenbeen.nl.

*                       IN      A       8.8.8.8

dnsserver               IN      A       8.8.8.8

As you can see, you can also add an asterisk (*) to answer the public IP on all public requests ending on .lab.breekeenbeen.nl. Before we can test the external request, you have to make a firewall rule which NAT all the UDP/53 request, to this server. Make sure if you’re going to test the configuration, that you do this from an external client and your DNS server set to your public IP. If you also want other requests for your domain coming to you through other DNS servers, you have to make a so called glue record at your domain hosting provider.

Upgrade Vmware on My Homelab

Wed, 17 Sep 2014 20:41:22 +0200

There are so many ways to update VMware that everytime they release a new version I can probably use a different one. Normally I really like this online way described on virtualGhetto. Although this time I’m going to use a different way, cause my new homelab consists of two ESXi servers, I only want to download the new update once and of course use/learn a new way of updating.

First of all get the desired update from the VMware website (account needed) https://my.vmware.com/group/vmware/patch#search Copy the downloaded update to the datastore which can be accessed by your ESXi servers. If you use NFS on a NAS (Synology) like me, it is pretty easy to copy this file with the use of Windows file sharing (if turned on), otherwise use WinSCP or another tool to access your datastore. I put my downloads in “__Management/Updates” (from a datastore perspective).

Put one of the hosts in maintenance mode, assuming you have configured a cluster and enough resources left. Otherwise, power-down your virtual machines. I find it good practice to check the file, before using it, to check this, click on the build number on the patch download site.

VMware update md5 hash

If you haven’t already, enable SSH. Log in with SSH on your ESXi server, browse to the update directory and run the following command.

~# md5sum update-from-esxi5.5-5.5_update02.zip
ea8c8486fffa0215df644f03b41c13f6 update-from-esxi5.5-5.5_update02.zip

If you find it interesting to see which modules have changed after the update, run this command, before you update.

esxcli software vib list

It will return something like this

VMware vibs installed

It will not return the current ESXi version, you can use the following command to accomplish that.

esxcli system version get

VMware esxi version before upgrade

Now we have checked almost everything on to the actual update. To check if everything wil run just fine, you can use the dry-run option

esxcli software vib update -d /vmfs/volumes/Gimli/\_\_Management/Updates/update-from-esxi5.5-5.5\_update02.zip --dry-run

If you are happy result, then let’s start the update

esxcli software vib update -d /vmfs/volumes/Gimli/\_\_Management/Updates/update-from-esxi5.5-5.5\_update02.zip

It can take a while and it seems nothing is happening, just be patient, eventually it will show something like.

VMware esxi version after upgrade

It will state if you have to reboot or not, if you want you can check the module versions again, if they are updated they will show a new version and date. If you are satisfied you can reboot.

reboot

After the reboot, check your version and if everything is functional as it should, if it does, exit maintenance mode and go on with the other server(s).

Loadbalancing VMware Horizon View Blast

Thu, 21 Aug 2014 19:39:05 +0200

One of the coolest features in my opinion of VMware Horizon View, is the Blast protocol. The Blast protocol makes it possible to connect and work on your desktop with just a browser and even better it does this all by making use of HTML5, no flash needed! (vCenter guys watch & learn from these guys) There already some good articles about load balancing VMware Horizon View to the outside world, however they all miss the part about how to load balance the Blast protocol to the outside world. Some good articles, worth reading:

Below I will describe how you could set-up VMware Horizon View including the Blast protocol. I will focus on the outside connections, which means the security servers. The set-up consists of the following components;

1 x outside firewall
2 x Loadbalancers (ADC)
2 x VMware View security server
2 x VMware View connection server
1 inside firewall, between security servers and connection servers (not important for this case)

Typical View HA set-up

This is how it actually works;

A user will connect to the VIP address (workplace.breekeenbeen.nl), this can be done by either using the client or a web browser, port 443.
This DNS entry contains a public IP address, let’s assume 8.8.8.8
The firewall will NAT this address to the VIP address of the ADC’s (in this set-up Active/Passive)
The ADC will determine which security server has to be used. Let’s assume round-robin, but in most ADC’s you can make more advanced rules.
The user logs in and the connection broker will do his job, to see if the user is allowed to access an available desktop. If this is true, the security server, will communicate a direct address for PCoIP or a direct address for Blast.
The user connects to this address and should be able to work on his/her desktop.

I have embolden the three most important variables, which you will also see, when you go to the View configuration of a security server.

External URL: VIP Address
PCoIP external URL: direct address for PCoIP
Blast external URL: direct address for Blast

I used the term direct address, cause this connection will not go through the ADC. So we need a separate public IP for the direct connections and NAT them to the internal IP’s of the server, for the connection to the security server, the NAT should work both ways! So our configuration would look like.

8.8.8.8 NAT > 10.1.1.8 (VIP ADC)
8.8.8.7 < NAT > 10.1.1.6 (Sec. server 1)
8.8.8.6 < NAT > 10.1.1.7 (Sec. server 2)

View connections (NAT)

Make sure in the security server configuration, you use the public IP addresses, cause an user would not know where to find the internal addresses. So a working configuration for this example, would look like this.

Security Server (NAT)

Although this is a perfectly working configuration, it has one caveat, when using Blast, it will redirect your browser to “https://8.8.8.6:8443”, this will result in an SSL warning, cause this IP is not the same as the certificates name “workspace.breekeenbeen.nl”. So what we want is, connecting to “ https://workspace.breekeenbeen.nl:8443”, this will result in a desktop through Blast without an SSL warning. However, we can use a public IP and port only once and we want also Blast to be spread over the two servers. Luckily we can easily do this by the use of Port-NAT, also called NAPT. Another benefit you gain by using NAPT is you really specify which ports to use, so this will more tighten the security. Especially watch the last line in the table below.

8.8.8.8:443 (T) NAPT > 10.1.1.8:443 (VIP ADC)
8.8.8.7:4172 (T/U) < NAPT > 10.1.1.6:4172 (PCoIP - Sec. server 1)
8.8.8.6:4172 (T/U) < NAPT > 10.1.1.7:4172 (PCoIP - Sec. server 2)
8.8.8.8:8443 (T) NAPT > 10.1.1.6:8443 (Blast - Sec. server 1)
8.8.8.6:8444 (T) NAPT > 10.1.1.7:8443 (Blast - Sec. server 2)

View connections (NAPT)

The security server configuration would look like this.

Security Server (NAPT)

Upgrade Vmware Horizon View 5.3 to 6.0

Mon, 04 Aug 2014 20:36:54 +0200

A little while back VMware released Horizon View 6.0, which comes with some neat new features, from which I think the RDS Hosted Apps is the biggest, for more information see VMware Horizon 6 What’s New on Ivo Beerens blog. This post is about getting your VMware Horizon View 5.3 upgraded to 6.0 on new servers (Server 2012R2), below I described the steps we have taken and resulted in a flawless migration with nearly no downtime for the end-user of course this is depending on your set-up. Keep in mind that the (re)compose function is not available during the upgrade.

The following steps are based on the excellent upgrade guide from VMware, the only difference is that the upgrade guide assumes that you upgrade your current servers, while the steps below are based on new servers. This way it is possible to also upgrade your OS from Windows Server 2008R2 to Windows Server 2012R2, keep in mind Server 2012 is not supported.

Before we actually get started it is good to find out which components are affected during the upgrade, these are not only the servers, but you also have to think about firewalls, load balancers, database servers and maybe active directory and/or some third party authentication tools like RSA SecureID. This particular setup is very basic and in short in consist of the following components, described from outside (internet) to inside;

Outside firewall
Outside/DMZ load balancer
Two secure connection brokers
Inside firewall
Two connection brokers paired to the secure connection brokers
Inside load balancer
Two connection brokers for the internal connections
One composer
RSA secureID

Now we know which servers are affected we can actually start. Here are the steps we took to upgrade this environment.

Build new servers based on Server 2012R2: If you count the VMware servers above, you will see that there are 7 servers that are going to be upgraded with VMware Horizon View 6.0.
Create a new image with the new View Agent in it and deploy it. From this point we stopped making changes to the infrastructure (compose, new pools, etc.).
Make a back-up of the View databases.
Installation & migration of the View Composer
1. Install the .NET 3.5 feature.
2. Copy the .NET RSA keys of the current server to the new server. Current: %windir%\Microsoft.NET\Framework\v2.0xxxxx, aspnet_regiis -px “SviKeyContainer” “keys.xml” –pri New: %windir%\Microsoft.NET\Framework\v2.0xxxxx, aspnet_regiis -pi “SviKeyContainer” “path\keys.xml” –exp
3. Disable provisioning in VMware View View Administration – servers – vCenter – disable provisioning
4. Install VMware View Composer on the new server
5. After installation change the server in VMware View Administration View Administration – Server – vCenter and click on edit and verify
6. Turn provisioning back on View Administration – servers – vCenter – enable provisioning
7. Turn off the “old” server
Installation & migration of the connection servers handling inside traffic repeat step A-F for every connection broker handling inside traffic
1. Start the installation of VMware Connection Server and choose for the install as replica option
2. Install the right certificate on the server (if needed)
3. Test the new server by going to the View Administration interface on this server. https://newserver/admin
4. Make sure the settings of the new servers are the same as the “old” ones
5. Make sure the firewall rules are updated with the new servers (if needed)
6. See if it is possible to connect with the View Client directly to the new connection servers.
7. Update the load balancer configuration with the new servers
8. Test if a connection through the load balancer is possible
Installation of the connected connection servers handling outside traffic (connected with security servers) Repeat for all the connection servers handling outside traffic
1. Start the installation of VMware Connection Server and choose for the install as replica option.
2. Install the right certificate on the server (if needed)
3. Test the new server by going to the View Administration interface on this server. https://newserver/admin
4. Create a new RSA authentication export file and import it to the new servers (if needed)
5. Make sure the settings are the same as the “old” ones
6. Make sure the firewall rules are updated with the new servers, change also the rules for connection from the new security servers.
7. See if it is possible to connect with the View Client directly to the new connection servers.
Installation & migration of the security servers Repeat A-F for all the security servers
1. Start the installation of VMware Connection Server and choose for the install as security server option
2. Connect the server (during installation) with the corresponding connection server
3. Install the right certificate on the server (if needed)
4. Test the new server by going to the View Administration interface on this server. https://newserver/admin
5. Make sure the settings are the same as the “old” ones
6. See if it is possible to connect with the View Client directly to the new connection servers.
7. Update the firewalls rules including NAT for PCOIP/Blast (if needed)
8. Update the load balancer configuration with the new servers
9. Test if a connection through the load balancer is possible
10. Test a connection from outside
Create a snapshot of the old connection and security servers
Remove the VMware View Connection software on both the connection servers and security servers.
If the servers still pop-up in View Administration remove them by running this command on one of the new connection servers. (we needed this) vdmadmin -S -r -s old-Connection_server
Remove old firewall rules (if needed)
Test if everything works as it should, recompose, new pool, etc.
If everything works correctly you may delete the old servers

Congratulations you’re now running VMware View Horizon 6.0 and unlocked a lot of nice new features!