Thursday, March 21, 2013

Step-by-Step Guide: Installing VMTools on Fedora18


Most of my viewers end up here while searching for information about installing VMware Tools on Fedora. In this post, I'm going to go over the process for VMTools on Fedora18.

As usual, I'm including an overview of the steps first, then I'll dive into the specifics.

Overview

  1. Update your kernel and installed packages.
  2. Install perl, gcc, and kernel-devel.
  3. Start the VMTools install (from the vSphere client).
  4. Copy the VMTools package to your fedora VM.
  5. Extract the VMTools package to /tmp.
  6. Run the install script.
  7. Run the configure script.

The Step-by-Step Guide

Ok. Let's get into the details. Each step in the Overview will be described in detail here. It may be overkill for those of you who are familiar with Linux administration, but this guide is really intended to help those who don't work with Linux often.

Update your kernel and installed packages.

Fedora offers a GUI-based method for updating your kernel and packages, but I recommend using the command line for this. I've seen some problems with the GUI-based method getting stuck on dependencies and just hanging. So let's do the command line way.

First, open Terminal, and become root: su -

Next, use yum to find and install updates for your kernel and the packages that are currently installed on your system: yum -y update

NOTE: The command I'm referencing here will update ALL packages. I'm partial to keeping systems up-to-date, so this is the method I've developed. At a minimum, you'll want to update your kernel.

After your updates have installed, reboot your VM: reboot

Log in again, launch Terminal, and check for updates once more: yum -y update

You should see a message that says, "No package marked for update." That means your system is current, and we're ready for the next step.

Install gcc, perl, and kernel-devel

Now that your system is current, let's get three new packages that are required to install VMTools: gcc, perl, and kernel-devel.

gcc is a compiler, perl is a scripting language, and kernel-devel is a package that includes source code for the linux kernel. Getting these packages is easy: yum can do it for you.

yum -y install perl
yum -y install gcc
yum -y install kernel-devel

Once these three packages are installed, you're ready to perform the VMTools install.

Start the VMTools Install (from the vSphere Client)

In your vSphere Client, find your Fedora18 VM and right click on it. Select the Guest menu, then choose Install / Update VMware Tools. Now go to your VM's console, and you should see this:

Click Open with Files to view the contents of the VMware Tools ISO (this ISO is mounted when you start the VMTools install / upgrade from the vSphere client).


Copy the VMTools package to your fedora VM

When Files opens the VMware Tools image, you'll see the screen shown on the right. This is a view of the contents of the VMTools ISO that vSphere has mounted to your virtual machine.












If you double-click the VMwareTools file, the Archive Manager will automatically launch and display the contents of the file. It's a single folder named vmware-tools-distrib. Notice that the title bar for this window says [read only]; that's because the file is still on the VMTools ISO. 










Extract the VMTools package to /tmp

Now we need to extract the contents of this file to your VM. Do so by right-clicking the vmware-tools-distrib folder and selecting Extract... You'll see a list of possible locations for the extracted files. I recommend extracting the files to /tmp, as seen in the image to the right. To find /tmp, first select File System in the Places pane, then scroll down until you find tmp in the pane to the right. Leave the Actions options at their default values, and click Extract.


When the Extract completes, you'll see a success message. There's no need to view the extracted files; the rest of the steps are done via the Terminal. Close the Archive Manager and Files, and launch a Terminal window (if you don't already have one running).

Run the install script

  1. In your Terminal session, su to root. (Type su - and enter the root password for your VM).
  2. Move to the /tmp directory (cd /tmp).
  3. Get a listing of the directories and files in /tmp (ls). You'll see vmware-tools-distrib listed here.
  4. Move to the vmware-tools-distrib directory (cd ./vmware-tools-distrib).
  5. Now start the installer (./vmware-install.pl).
The installer may take 15 seconds to get set up. Once it starts, you can accept the defaults for the options. Once you've supplied all of the information (again, the defaults are fine here), the vmware-install.pl script will offer to launch the vmware-config-tools.pl script to complete the install. Hit Enter to continue.

Run the configure script

It's safe to accept the defaults for the configure script, with one significant exception. When the script asks about the path to the kernel headers, you need to pay attention. You may see this: 

The problem is that the script thinks it has located valid kernel headers in a path named "". But this is a bad path. If you hit Enter here, the script will continue for a moment, then fail. So we need to change the path. Leave this script at the headers prompt, and open a new Terminal tab to perform the following steps.

First, you'll want to find the specific file that the config script is looking for: version.h. It's on your system, just not where the config script is looking. Here's how to find it.

  1. Change to the /usr/src/kernels directory (cd /usr/src/kernels).
  2. Change to the directory that matches your running kernel, probably the latest version. In this case, since I'm running 3.8.3.-203, I would do cd 3.8.3-203.fc18.x86_64.
  3. Change to the following directory: cd /include/generated/uapi/linux.
The version.h file is located here. In my case, the full path is /usr/src/kernels/3.8.3-203.fc18.x86_64/include/generated/uapi/linux/version.h. This is the file that the config script is looking for. We just need to copy it to a location where the script can find it. That location (again, in my example) is:

/lib/modules/3.8.3-203.fc18.x86_64/build/include

To copy the file, enter the following command:

cp /usr/src/kernels/3.8.3-203.fc18.x86_64/include/generated/uapi/linux/version.h /lib/modules/3.8.3-203.fc18.x86_64/build/include

Now, you're good to go. Go back to the first Terminal tab. Change the location for the headers file to /lib/modules/3.8.3-203.fc18.x86_64/build/include, and you'll be good to go.

Accept the rest of the defaults, and the script will complete successfully. When it's done, you'll see that the VMTools status in your vSphere Client has changed to Running (Current).

Wasn't that easy? :)

Sunday, March 17, 2013

Protip: Autostart your vCenter Server Appliance

If you're like me, you have a simmering love / hate relationship with the vCenter Server Appliance. It goes something like this:

LOVE
  • Removes the need for a Windows host for your vCenter

HATE
  • No vSphere Update Manager
In my opinion, this makes the vCenter Server Appliance great for lab and small environments, but if you're running a bigger deployment you'll want to stick with the traditional vCenter Server on a Windows host. Until VUM is an option (and VMware would be foolish to not add this feature ASAP), the vCSA is not the droid you're looking for.

But the point of this post is this: regardless of what platform you're using for your vCenter Server, you'll want to set that VM to start automatically. By default, your VMs are configured to start manually. Consider a lab environment with two ESXi 5.1 hosts. You may want to shut your lab down at the end of each day to extend your trial license save energy. That's cool.
vCenter Server Appliance, stopped.

When you start your lab up the next morning, your vCenter Server Appliance won't start up unless you've told it to. In that case, you'll need to use the vSphere Client (which is quickly becoming old and busted when compared with the new hotness of the Web Client) to start up vCenter. And if you're a Mac / Ubuntu / Fedora / anything-but-Windows user like me, that's a pain.

Instead, tell that VM to start automatically. Here's how:

We'll start with enabling your VM to start up automatically on a single ESXi 5.1 host.
  1. Connect to the host with the vSphere Client.
  2. Select the Configuration Tab, and find the Virtual Machine Startup / Shutdown item from the Software section of the screen. You'll see a list of the virtual machines that are registered to the host, and a summary of their startup / shutdown behavior.
  3. Click the Properties... link in the upper right to get to the Virtual Machine Startup and Shutdown screen.
  4. The Virtual Machine Startup and Shutdown properties screen.
    To have your vCenter VM start up automatically with your host, check the top box. Doing so will allow you to configure your VMs in the next step.
  5. Click your vCenter VM once to select it, then click the Move Up button until the VM is listed under the Automatic Startup section.
  6. Click OK, and you're set.
Now when your restart this particular host, the vCenter VM will start automatically. 

Duplicate and triplicate, dead from the neck up.
Side note: I've noticed (twice in the last three days, in fact) that once you set the startup options for a VM, the VM will show up three times in the Startup / Shutdown screen. Clicking away, then coming back makes the problem go away, and it doesn't have an effect on the operation of your VM. Just a weird bug.

So let's talk about what we've done for a minute. We just configured a single ESXi host to automatically start up the VM that runs your vCenter Server. But what happens when that VM is vMotioned to another host in your cluster? Will the changes we just made follow the VM?

Short answer: no. So we need to do something different to make sure that this VM starts up automatically no matter when it ends up. ....And since it's nearly 1AM, we'll leave that for another day.

mike

Tuesday, March 12, 2013

#169

The vSphere-land.com top VMware blog listing was released yesterday, and I'm happy to be ranked at #169! Participating in the community has always been my goal with this blog (I'm clearly not doing this for the fame or fortune :) ), and it's flattering to be on the list at all. Many thanks to Eric Siebert for once again putting in a non-trivial amount of work in getting this contest together.

The last few weeks have been busy, so I'm not posting as often as I'd like. I've got lots of drafts that I need to finish up and send off. I'll get at least one of those out this evening.

So thank you to the readers who cast their votes for me. I'm humbled and inspired to keep posting content that you can use in your adventures with VMware.

mike