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 or more newer hosts (newer architecture processor)
- 1 or more older hosts (older architecture processor)
- All have ESX/ESXi configured identically
- The only difference is the actual CPUs used in the hosts
- You know the CPUs are not compatible for VMotion purposes
You will see:
- 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)
- 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.
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
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