Home > Virtualization > OpsCheck from Tripwire

OpsCheck from Tripwire

February 17th, 2009 Jase Leave a comment Go to comments

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.

Categories: Virtualization Tags:
  1. Mike
    February 17th, 2009 at 12:46 | #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. Jase McCarty
    February 17th, 2009 at 13:40 | #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

  1. No trackbacks yet.
Please leave these two fields as-is:

Protected by Invisible Defender. Showed 403 to 942 bad guys.