Community Fatigue

No, not this community.

Seems like #community is all we talk / tweet / blog / podcast about these days. And for a good reason: establishing and maintaining a presence in the technical community of your choice is a great way to develop your personal brand, build relationships, and promote your skills a bit. Software and hardware companies figured this out a while ago, which is why the number of communities has grown so rapidly over the last year or two (or in cases where the community has been established, you'll notice a recent marketing push to attract new members).

Many communities have adopted gamification as a means to attract new eyeballs and keep them on the site longer. I know that lately, I'm addicted to thwack. I'm chasing those points like I use to chase 'chieves in WoW. I scored a coffee cup (almost as nice as my old NPR mug) and a t-shirt in the process. I watched my rank in the community climb, and my level climb, too. I've had a few great discussions along the way, so it's not entirely artificial. But it does make me wonder if I'd participate as frequently without the incentive.

After a few weeks of thwack, I realized I hadn't paid attention to the VMware and Cisco communities as much as I'd like. And then I thought about Spiceworks. And then NetApp and EMC's communities. And then I realized that there truly are too many technical communities for a single person to participate in and actually share & learn, as opposed to just rack up points. At least, you can't participate in them all if you're employed and like your family. Which I am, and I do.

We've hit community fatigue, people.

You should quit worrying, too. See how happy he is?

My advice is to pick one or two communities that you like and stick with them. I do like thwack; it's fun and goofy, kind of like SolarWinds in general. But don't let the laid back atmosphere fool you: you'll find plenty of battle-tested IT pros there who are happy to share what they've learned. And since I'm still in love with vSphere, I browse the threads at VMTN daily. But I've learned to quit worrying about my points with Cisco and others. I'd rather build a strong reputation with a few communities, than weak reputations with many communities.

Target CPU Utilization on ESXi Hosts

I was asked an interesting question a few days ago during a discussion about virtualization and cloud computing. The context of the question was observed CPU percent utilization on physical hosts prior to converting them to VMs. Here's the question:

What do you think a good target is for CPU Utilization on an ESXi host?

I admit that it was tempting to throw out a number to answer the question. But I realized that I had just been given a great opportunity to educate someone on some vSphere design considerations. And you'll be happy to learn that at no time did I ever utter those ill-fated words: IT DEPENDS. (Even though in this case, it really does.)

Instead of blurting out a target, I explained that we needed to establish some facts about the vSphere environment. Do they have a cluster? Seems like a stupid question, but you'd be surprised how many sites I visit with plenty of stand-alone vSphere hosts. If you do have a cluster, how many hosts does the cluster have? What's your expected failover capability? (Note the use of "expected;" actual configurations sometimes don't provide the expected failover capability.) What's your workload profile? What's the planned growth factor for your workloads?

Basically, I found myself having flashbacks from reading the vSphere 5.1 Clustering Deep Dive book.

I love recognizing opportunities like this one. After all, that's what consulting is about. Not just answering questions, but helping people ask the right questions, and walking them through the solution.

open-vm-tools installation on Fedora 17, 18, and 19

Most people end up at the #eager0 looking for help installing VMTools on various Linux distros and releases. My posts about Fedora 17 and Fedora 18 sit at the top of my most viewed posts list (that is until VMware's Facebook page gave me some love, and my crash course on Cloud Computing shot up to the number two spot).

I'm rebuilding my home lab (which wouldn't be possible without the support from Chesapeake NetCraftsmen!) these days, and as part of that effort I've been deploying some Fedora VMs again. But this time I thought I'd try something different: using open-vm-tools instead of the native VMware supplied VMTools. I've had success, and thought I'd share what I learned with you.

VMTools Status in the vSphere Client.

If you've ever run a virtual appliance, you've used open-vm-tools. You probably just didn't know it. The image to the right is the give-away.

open-vm-tools is easy to get up and running on a Fedora VM. MUCH easier than using the VMware provided VMTools. Of course, you'll trade functionality for simplicity: open-vm-tools will provide you with the core functionality of VMTools: the ability to request a graceful shutdown of your guest OS from your vSphere Web Client (or god forbid, the vSphere Client). VMware's VMTools for Linux has many other features that may be of use to you; I'll catalog those in a future post. For now, let's go over the open-vm-tools bit.

Now for the good news: open-vm-tools ships with Fedora 19, and will start automatically if Fedora detects that it's running as a VM on VMware software. So... you don't need to do anything! Pretty easy, right?

For Fedora 17 and 18, you'll need to grab the open-vm-tools package through yum:

sudo yum install open-vm-tools

Then reboot to complete the install and verify that open-vm-tools starts up properly. You're looking for that tell-tale sign above: VMware Tools: Running (3rd-party/Independent).

It's nice to see the inclusion of open-vm-tools in Fedora 19. It's even nicer that it is smart enough to run when it's needed. Unless you require those other features (many of which are beta) of VMTools, I highly recommend sticking with open-vm-tools for your Fedora boxes.