Clean VMware Update Manager on VCSA 6.5

Update Manager on VCSA 6.5

Conflicting VIBs during patching? Changing server vendors? Want to get rid of an old repository? All of the above?

I just ran into this scenario again, where a customer is changing from one server vendor to another. There was an Update Manager repository for the old server vendor, and those vendor-specific, conflicting patches for both critical and non-critical patches were included in the default baselines.

There is no nice way to remove individual patches or an entire repository worth of patches from the internal database. Instead, we must start from scratch. Take note of your settings, check your backups, take a snapshot, and reset Update Manager back to defaults.

Connect to vCenter Server Appliance 6.5 via SSH

Run the shell command to switch to the BASH Shell:

shell

Stop the VMware Update Manager Service:

service-control --stop vmware-updatemgr 

Run the following command to reset the VMware Update Manager Database:

/usr/lib/vmware-updatemgr/bin/updatemgr-util reset-db

Run the following Command to delete the contents of the VMware Update Manager Patch Store:

rm -rf /storage/updatemgr/patch-store/*

Start the VMware Update Manager Service:

service-control --start vmware-updatemgr

The only things left to do is to log out, log back in, and you’ve got a fresh Update Manager waiting for your configuration. Don’t forget to clean up your snapshot!

See KB2147284 if you have any other questions, or comment below.

Quick and Dirty With vCheck

This is the second of [?] posts, participating in Blogtober in the virtualization community.

So, maybe you’ve heard how cool vCheck is, but you’re just not sure where to get started. If you aren’t sure what it is, check out this post by its creator, Alan Renauf.

Now that I have you at least semi-interested, let’s get started.

Install PowerCLI

Grab PowerCLI – you can grab it as a Powershell module now. It also auto-loads pieces as it needs, which is really convenient.

  1. Uninstall existing all PowerCLI versions
  2. Fire up Powershell
    1. Make sure you can access the Powershell Gallery
    2. Installs the modules as the current user (or run PS as admin, skip the “-Scope CurrentUser” option to install for all users)
Find-Module -Name VMware.PowerCLI
Install-Module -Name VMware.PowerCLI –Scope CurrentUser

For a more detailed look, check this blog post.

Downloading vCheck

Grab the latest version from the GitHub Repo: https://github.com/alanrenouf/vCheck-vSphere/releases

At the time of this writing, we’re grabbing the 6.24 release (August 24, 2017).

Unzip it to your favorite place for stuff like this. In this example, C:\Utilities\vCheck.

Configuration

In your Powershell window, navigate to where you unzipped vCheck.

You have to load some custom functions, you’ll need to “dot source” the utility file, which loads some functions for you to launch later if you want (export and import settings, for example).

PS C:\Utilities\vCheck\> . .\vCheckUtils.ps1

Now that you’ve got the functions loaded, you can do things like import/export your settings, add/remove plugins. For the initial config, there’s a nifty gui configuration you can use, just fire it up like this:

PS C:\Utilities\vCheck\> .\vCheck.ps1 -GUIConfig

You can list plugins, remove plugins you won’t use:

PS C:\Utilities\vCheck\> Get-vCheckPlugin --Installed
PS C:\Utilities\vCheck\> Remove-vCheckPlugin "Name Here"

Following, setup the scheduler (probably want to do this on a server) you loaded from the vCheckUtils.ps1 functions.

PS C:\Utilities\vCheck\> Schedule-vCheck

Give it a shot and see what it’s like:

PS C:\Utilities\vCheck\> .\vCheck.ps1

Rob Nelson has a more in-depth post if you’re looking for more.

vSphere CPU ready time

Bored, nothing to do, and checking out your performance metrics?  First off, use VMware vRealize Operations (vROps, formerly vCOps), and take up a new hobby in all your spare time; thank me later.  Still need to take a look because you’re troubleshooting a slow VM?  Concerned about if you’re oversubscribing your CPUs?  High kernel times?

Why can't I hold all of these metrics

A basic explanation of CPU Ready Time is: how long is your virtual machine is waiting in line to use the CPU on the host?  There is a very acceptable percentage (in general, under 10%, more on that below), however oversubscribing will definitely cause you (or clients) headaches.  An example of when you have this problem is a generally slow VM, but task manager/TOP isn’t showing something eating up all your CPU, and all other metrics look fine.  Extreme cases will make the VM’s clock slow.  Perhaps high kernel time?  Josh at vmtoday has an image of this example on his very relevant post.

When you look at these graphs and see high numbers, don’t necessarily worry.  There’s a pretty easy formula to figure out what you’re looking at.  In the example I’m using below, I’m using the performance chart for the VM, realtime, which has a metric rollup time of 20 seconds.  Here’s how I got it to that, and what it looks like:

 

Performance Options
Performance Options

Realtime CPU Ready
Realtime CPU Ready

If you’re looking at graphs of different timeframes, you want to use a separate number in the formula:

  • Realtime: 20 seconds – We’re using this one in my example
  • Past Day: 5 minutes (300 seconds)
  • Past Week: 30 minutes (1800 seconds)
  • Past Month: 2 hours (7200 seconds)
  • Past Year: 1 day (86400 seconds)

(CPU summation value / (<Chart Interval in Seconds> * 1000)) * 100 = % CPU ready

It’s probably hard to see, but I’m interested in the VM average of 547 at a realtime (20 second) interval.  I toss those numbers into the formula:

(547 / (20 seconds * 1000)) * 100 = 2.73% CPU Ready

With only 2.73% CPU ready time, I can see this VM isn’t having any CPU problems.

Some different resources concur that up to 10% is acceptable, but something over 10% should require some reviewing.  Keep in mind the time-frame you’re looking at this:  realtime during high production times may not be the most accurate for an overview.  If that’s the case, check out a daily or weekly average instead.

Additional resources on this topic including all about using CPU affinity: