April 18, 2024

OpsCheck from Tripwire

Well, Tripwire released another free tool today, OpsCheck.

Pretty nifty little java based application to check for inconsistencies between hosts and VM’s to make sure that a vMotion could occur from one host to another (or one of many).

I figured I’d fire it up, and see what gives.

When you go to perform an “Operational Check”, you have the choice to scan a single cluster, or scan up to 10 hosts in different clusters. I would imagine that if you have more than 10 hosts in a cluster you would be fine as well. At least that is what the documentation leads me to believe.

So I fired it up, and pointed it at cluster I use for some testing. I have some VM’s on this cluster, but not many.

Here is what I found after running a check:


Woo-Hoo! No host issues, and I only had 1 VM with an issue. So what was the issue?


A doggone attached CDROM. Well, that’s good to know.

Now, I will mention that all of the hosts in the cluster, are the same processor type, the networks are 100% identical at the host level, and yada yada yada.

So what happens if I run OpsCheck against all 8 of my hosts? I have 4 that are several year old IBM boxes, and I have 4 that are brand new HP boxes. Of course the processors are going to have VMotion issues.

Given that OpsCheck checks at both the VM and Host levels, here is something I have found…

If you have:

  1. 1 or more newer hosts (newer architecture processor)
  2. 1 or more older hosts (older architecture processor)
  3. All have ESX/ESXi configured identically
  4. The only difference is the actual CPUs used in the hosts
  5. You know the CPUs are not compatible for VMotion purposes

You will see:

  1. A VM on an old host will have an issue with all new hosts (1 or more issues listed, depending on how many incompatible hosts)
  2. The opposite, A VM on a new host will have an issue with all old hosts (1 or more issues listed, again)

Here’s an example running it across 4 IBM x445 boxes, and 4 HP DL580 G5 boxes:

I’m not going to try to do the math… But with over 300 guests, across 8 hosts, you can see there are going to be some compatibility issues when half the hosts are old, and half the hosts are new.

Regardless, this is a really cool tool, and as I can see from the above graphic, I’ve got 14 VM’s to troubleshoot. That’s the last time I let someone else take point on the VMware environment.

Cheers.

2 thoughts on “OpsCheck from Tripwire

  1. Hi Jase – In response to your comment “I would imagine that if you have more than 10 hosts in a cluster you
    would be fine as well.”

    Tripwire states 10 hosts due for performance and support purposes for a free tool. However, during internal performance
    testing when OpsCheck was from the command line interface, it analyzed VMotion configuration data for
    26 hosts and 1048 VMs in approximately 6 1/2 mins.

    Issues by Issue Type:
    20 Host
    468 HostToHost
    1197 Vm
    52752 VmToHost

    Issues by Issue Level:
    54437 Error

    Issues by Issue Name:
    376 DifferentPortGroupAllowPromiscuous
    90 DifferentPortGroupMacChanges
    2 HostMountDifferentPath
    20 HostNotVmotionEnabled
    1190 VmConnectedDeviceCd
    450 VmConnectedDeviceCdMissingTargetStorage
    1 VmCpuAffinity
    3524 VmHostCpuVmotionIncompatibility
    22598 VmHostMissingNetwork
    26180 VmHostMissingStorage
    6 VmMountsInternalSwitch

    -MC

  2. Hey Mike,

    I agree 100% with what you stated.

    I think it is a great tool!

    I just wanted to make sure that people understood what I saw, and how to appropriately read it.

    After using OpsCheck 1 time, I can’t imagine how to go on without it!

    Thanks for a great tool!
    Jase

Leave a Reply to Jase McCarty Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.