vmware

Run DRS

by

In my role as a Technical Account Manager (TAM), I get to work with highly skilled engineers and architects at our customers and partners that put VMware’s products to great use in their datacenters. And even though I am pretty used to all the positive impact these products deliver, I still enjoy seeing the long-term benefits of vSphere happening every day.

One of the examples I’d like to share today is the usage of VMware’s Distributed Resource Scheduler (DRS). This technology has been introduced more than six years ago and still plays a key role to the core virtualization infrastructure. DRS automates the migration process vMotion to load-balance virtual machines across ESXi hosts in a vSphere Cluster.

Last year, the DRS fans and bloggers Frank Denneman and Duncan Epping even came up with a great t-shirt design for VMworld:

run_drs_shirt

“Run DRS” – this is exactly what a customer of mine is doing with huge success. They were so kind to send me a screenshot of one of their vSphere clusters including the current amount of vMotion processes (initiated by DRS) that happened in the past 1.5 years:

DRS_vMotion

More than 18.000 vMotions in one vSphere Cluster. In less than 1.5 years. That’s roughly 30 vMotions per day. It’s hard to imagine what the datacenter operations team would do without this. But they implemented a well-designed architecture and benefit from the flexibility of this technology every day. Do you?

Horizon Workspace behind a DMZ loadbalancer

by

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!

Orchestrating Enterprise Environments with vCenter Orchestrator

by

In this post, I would like to share some recently published material around VMware vCenter Orchestrator (vCO).

First of all, vCO has been released as virtual appliance that can be downloaded from VMware.com. You can find an overview in the vCO Team Blog post at VMware released the vCenter Orchestrator Virtual Appliance.

Furthermore, three videos on developing vCO Workflows have been published on the VMwareTV Youtube Channel.

Part 1:

Part 2:

Part 3: