VMware Tools – Settings Time Sync Settings via the CLI

With the latest and greatest VMware Tools updates, you may have noticed a change to the VMware Tools Toolbox. Mainly, the inability to do anything that you used to be able to do. Now you are simply greeted with the version, some copyright information and a status that tells you if the service is running or not.

vmwaretools_toolbox

This change is outlined in the ESXi 5.1u1 notes as follows:

VMware Toolbox. vSphere 5.1 is the last release to include support for the VMware Tools graphical user interface, VMware Toolbox. VMware will continue to update and support the Toolbox command-line interface (CLI) to perform all VMware Tools functions.

Sweet, we can still do some of this via the cmd line. Even though I’m a Unix admin, I know that many of my customers are Windows guys so my example will be for windows. I found the following guide that is a bit dated, but the commands still work and are pretty straight forward.

  1. Open a command prompt
  2. cd c:\Program Files\VMware\VMware Tools\
  3. VMwareToolboxCmd.exe timesync status
  4. Then to change: VMwareToolboxCmd.exe timesync {Enable | Disable}

Here’s a quick screen shot walking you through the checking of the status and setting the timesync state both to enable and disabled.

enabling_and_disabling_timesync

Quick and easy to change, but not as easy as it used to be. Hopefully this helps anyone running the latest and greatest VMware Tools and setting their time synchronization settings.

Puppet Error: Could not retrieve local facts: undefined method `kernel_fact_value’

Recently while patching some CentOS boxes in my lab, I noticed the following error.

May  5 13:48:38 <hostname> puppet-agent[19924]: Could not run Puppet
configuration client: Could not retrieve local facts: undefined method
 `kernel_fact_value' for Facter::Util::Processor:Module

This was a bit odd as one of the things that I will typically do when I see puppet or facter updates in my update list is to run the agent manually with a

puppet agent -t

Since that came back clean, I was a little surprised when I checked into the dashboard later in the day to see nodes failing on me.

Doing a little research into the error led me to the following bug report. The fix for me is pretty simple, restart the agent on the node and everything works itself out. If you had a large environment, this could be really damn annoying having to log into every box since puppet no longer works for you.

VCP-IaaS Exam Experience

This morning, I passed the VCP-IaaS exam making me an official VCP-Cloud.

Overall, I found the test to be a nice add-on to the VCP5 test that I took back in 2011 and not as hard as I was expecting it to be. Don’t get me wrong, you have to know your stuff. But I think of all the tests that I’ve taken from VMware, this one was more in line of what you would encounter on a day-to-day basis as a vCloud Administrator which is what I think certification tests should be rather than pure memorization of the admin guides. This could be that my role over the past 6 months has been to roll out a vCloud environment, produce a bunch of internal documentation and training, and find new and interesting ways to break the environment.

I can’t discuss actual questions from the test itself, but I can tell you what I did to prepare.

  • If you have the equipment, setup a home lab. If not, find a way to set it up at work even if it is just a proof of concept somewhere. I was very fortunate that deploying vCloud was one of my main projects so I had a great playground to work with.
  • Pour over the documentation. This seems like an obvious answer, but the blueprint spells out exactly what is on the test so read all the documentation surrounding those sections. I find that I read the documentation once, then I go back and look for all the ‘note’ sections and best practices and then try to come up with a question that gives a situation showing the opposite of the best practice. It’s a way of training the brain for some the questions that are going to be coming at you in the test.
  • Find study note blogs. There are a ton of them out there and these will often do the work of the previous suggestion for you, but I like to make sure I’ve thoroughly read the documentation before looking at someone else’s cliff notes.
  • Listen to the vBrownBag Podcasts. These guys have been knocking it out of the park for a while now. I downloaded and listened to all the VCP-IaaS related podcasts over the past several days to have another avenue of the information coming in. Read it, hear it, do it. I think it covers all the learning styles out there. Surely something will sink in.

By far, the hardest part for me on the test was the ChargeBack items as its the area where I have the least amount of experience. That’s probably where I spent the most time studying for this exam and from what I’ve heard from others, it was a pretty similar experience.

That’s pretty much it. Good luck to anyone out there that is taking the test.

vCloud – Licensing error while accessing vSphere Profile-Driven Storage

Recently I was spooling up a dedicate cluster of hardware for a customer in our vCloud environment. It’s a smallish cluster of 5 hosts with a dedicated pool of storage. Nothing out of the ordinary here. Created the DRS/HA Host Cluster. The storage guys had already done the various zoning and disk LUN creation so that was added to the cluster and tagged it with a User Defined Storage Capability.

storage_profile_error2

Which then was linked with a Storage profile so we could use that in vCloud. Again, nothing out of the ordinary.

storage_profile_error3

So let’s create a vApp to make sure everything is working as expected.

storage_profile_error1

Son of a #*$&! We missed something here along the way. At least the error message we got was pretty straight forward. </sarcasm>

Licensing error while accessing vSphere Profile-Driven Storage Service, VM Storage Profiles are not enabled for the VMs host.

storage_profile_error5

Uh…what? We have enterprise plus licenses on these hosts which supports storage profiles. So the hosts surely support it. The storage profile setup went through with no problems. So what’s the issue?

The Solution

The issue turns out to be a setting I missed while setting up the Storage Profiles. On the upper right hand side of the screen (see second screenshot on this post), you will see an option for Enable VM Storage Profiles. Click on that link and you will see your various clusters and sure enough, the cluster I have set up for this vDC has a VM Storage Profile Status of unknown.

storage_profile_error4

Luckily, it’s a simple highlight and click of the Enable button and you are good to go.

So there you have it. I figured this is a minor misstep in my setup process but I should share the knowledge so hopefully others won’t trip up as well.

NOTE: Some screenshots edited to hide host and customer names.

Puppet Dashboard – Inventory Service

As a user of the free version of the Puppet Dashboard, I’m always looking for little tips and tricks that can make it more useful in my day to day job. Some of the features that you find in the Puppet Enterprise (PE) version are available in the free version, it just takes a bit of time and effort to get working for you.

One of those features was recently brought to my attention by a co-worker. In the Puppet Dashboard, its possible to have the facts of your node presented within the web UI. PE does this by default, but in the open source version you have to do a little wrench turning to get it working. My co-worker had already gotten it working on our production environment, but I wanted to see what it took to get running in my lab.

Here’s the great part about all of this…its really freaking easy to setup!

The Setup

  1. First and foremost, read the documentation found at http://docs.puppetlabs.com/dashboard/manual/1.2/configuring.html
  2. Update your /etc/puppet/auth.conf to allow for the dashboard to connect to the service. The docs state to use this:
    path /facts
    auth yes
    method find, search
    allow dashboard

    but I found other examples online that used the following. My guess is they changed the auth and allow lines when they got a permission denied error like I initially did. This second one did the trick for my lab and since its all internal networking and not accessible to anyone on the outside world…I felt it safe to not use the SSL auth between puppet and the dashboard running on the same host.

    path /facts
    auth any
    method find, search
    allow *
  3. Update your Puppet Dashboard settings.yml (mine was in /usr/share/puppet-dashboard/config/settings.yml)

    This one is pretty simple to do. Change the enable_inventory_service from false to true. Also double check your inventory_server line to make sure it has a valid entry. I forced mine to localhost.

  4. Restart Puppet-dashboard (CentOS start up scripts do a crappy job of this. actually had to stop, then start the process)
  5. Go to your dashboard and find a node. You should see some extra bits. Check out the before and after shots below.

The Results

Before:
Before we had our Recent Reports followed by our Dashboard Activity.

inventory_before

After:
And after we have a nice invetory section between them. (NOTE: I did have to cut out the node names in the following image to protect the innocent)
inventory_after