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:
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:
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.