Friday, March 21, 2014

Why End-to-End Monitoring is Critical

Monitoring the pieces is NOT the same as monitoring the whole.
When it comes to monitoring, most people have a good idea of what infrastructure components need to be monitored. In a vSphere environment, it's commonplace to monitor the health and performance of the virtual machines, the ESXi hosts, the upstream network switches, and the storage platform. You might use different tools for each component (even though I think that's a bad idea in general), but you're effectively monitoring each part of your vSphere infrastructure.

But there's one major gap in this approach: you're missing end-to-end monitoring.

I've been thinking about this situation lately. It's a result of a problem from earlier in the week. Some VMs were reporting very high disk latency (spiking between 100 and 200 ms). And as usual, the storage engineers said that the SAN was fine, the virt guys said that ESXi was fine, and the Windows guys said that the VM's OS was fine. So in the midst of every piece being "fine," we had a VM in trouble.

The Forest or the Trees?

In this scenario, each component of the virtualization infrastructure was being monitored. But the infrastructure as a collection of components was unmonitored. The connections between the components were invisible to monitoring. Production workloads were failing, and the root cause couldn't be identified. Sure, each tree seemed healthy, but the forest was on fire.

A Case for vCOps

I've liked vCOps for e2e monitoring for a while now. It's intended to solve the very problem described above (in addition to lots of other functionality that I won't go into here). It enables you to quit micro-monitoring your infrastructure, and start monitoring your workloads. This is a subtle but significant shift from traditional monitoring, and in my experience, it's still a new concept for most IT shops.

What's the Point?

The point is this: regardless of the solution you use, end-to-end monitoring of your virtualization infrastructure is no longer a want; it's a need. End-to-end monitoring can eliminate (or at least reduce) finger-pointing when performance problems creep into your systems, and can alert you to capacity problems before they affect operations. Deploying vCOps is so easy to do, you'll wonder why you hadn't done it a year ago. So go do it today.

Thursday, March 13, 2014

SNUG, then VMUG

I completed a user group duathlon yesterday: the ServiceNow Users Group and the DC VMware Users Group. I totally lucked out, since both events were in McLean, VA. Here's a bit of what I learned from each.

SNUG

I like ServiceNow more and more these days. In the past, I would have discarded ServiceNow as ticketing software. That'd be like saying VMware is just a x86 virt platform. Yesterday's SNUG had a great presentation on the strategic direction of the company, as imagined by Dave Wright, ServiceNow's Chief Strategy Officer. He talked about the evolution from Help Desk to Service Relationship Management, and how IT can mature from a provider of technologies to a provider of services. He also explained the four pillars of SRM:
  1. Service Experience
  2. Record Keeping
  3. Process Automation
  4. Business Management
If you want to see a presentation similar to the one given at SNUG, click here.

It turns out that Dave Wright was the Vice President of Technical Services, EMEA for VMware for six years. Which made for a great segue as I ducked out a few minutes early to avoid introducing myself to the group to get to the DCVMUG in time.

VMUG

VMUGs are always great. You get to chat with bright people with a variety of backgrounds in virtualization technologies. We listened as Brad Clemmons (a VMware staff engineer) talk about VMware's roadmap for the SDDC, which is starting to fill out now with the introduction of VSAN and NSX. And we learned that the rumors of vCD's demise are mostly untrue. While much of its functionality is being split into vCAC and vCenter, vCD will persist as a product geared to Service Providers.

Nexenta presented their SDS offerings, specifically for VDI. Their interface for provisioning storage as part of deploying virtual desktops was pretty slick. It was a great, tangible example of what SDS can look like.

------------------

As always, I highly recommend attending these community-building events, no matter what your technical or business interests may be. 

Monday, March 3, 2014

vmtoolsd on Fedora 20

You just loaded up a new VM with Fedora 20 in Fusion, and you're getting ready to load up VMTools as part of your build process. So you head over to the Virtual Machine menu, but you don't see an option to install VMTools. Just an option to re-install. How can this be?

Last spring, a bug was filed to start vmtoolsd automatically if the OS detects that it's running on a VMware infrastructure. Pretty slick. open-vm-tools has been included with Fedora since 17, but it wouldn't start automatically. That led to many admins loading up VMware's VMTools when they didn't need to. Not a big deal, really. But it's time that could be spent on other tasks (and sometimes, installing VMware's VMTools can be messy).

So how does vmtoolsd know when to start? It's surprisingly simple and elegant, as far as Linux config files goes. Fire up your Terminal and let's see what's going on here.

The vmtoolsd.service file

The vmtoolsd.service file located at /etc/systemd/system/multi-user.target.wants contains a statement that makes this auto-start on VMware products possible. It's the ConditionVirtualization=vmware statement on line 4.

This statement will make vmtoolsd start automatically when the OS detects that it's running on a VMware product. vmtoolsd will start automatically when the VM is running on any VMware hypervisor, and will NOT start if it's hosted on any other hypervisor.

So quit worrying about loading up VMTools on your Fedora VMs. open-vm-tools is on the job.