Introduction
VMware’s VMotion is one of the core features of the Virtual Infrastructure Enterprise suite. VMotion will move your virtual guest machines from one ESX Server to another without the VM guest ever suffering any downtime. VMotion is used with Distributed Resource Scheduler (DRS) to balance the load of the VM Guests across the virtual infrastructure.
While VMotion is not too difficult to configure, you do want that critical piece to work and work the first time. Plus, you want its configuration to be optimized according to VMware’s best practices. This is the power of OpsCheck. And, better yet, OpsCheck is free from TripWire.
Where do I get OpsCheck?
TripWire has created a new community called vWire. At the vWire community, you can download two free VMware tools (there are more on the way) and visit their virtualization community (as a side note, you can even get a free tshirt if you refer a friend). The two free VMware tools that are offered are ConfigCheck and OpsCheck. ConfigCheck is a VMware security assessment tool (you can learn more about it in my article Assessing VMware ESX server security with TripWire ConfigCheck). OpsCheck, on the other hand, is the VMotion verification and best practice analysis tool.
Downloading OpsCheck is quick and easy. It is a very small tool of only 7.5MB. There is no installation. In fact, OpsCheck is really a Windows command script that calls and executable Java JAR file. I downloaded OpsCheck and unzipped the file. I ran the opscheck windows command script.
Figure 1: Running the OpsCheck Windows Command Script
A Windows command window appeared, accepted the end-user license agreement, and TripWire OpsCheck version 1.0.0 appeared.
Figure 2: Logging OpsCheck into your Virtual Infrastructure
In order to use OpsCheck and VMotion, you need to have Virtual Center (vCenter) running. Thus, there is no need to try out OpsCheck if you do not have Virtual Center and vMotion.
To connect OpsCheck to your vCenter server, you need to provide the hostname for vCenter, username, and password. As you see in Figure 2, I did this, then clicked Login and Continue.
You will know when OpsCheck has logged into vCenter because it will show you an inventory of your Clusters and ESX Hosts, as you see in Figure 3.
Figure 3: OpsCheck has listed out my clusters and hosts
From here, all you have to do is to either select 2 or more ESX hosts or a cluster. In my case, I selected ESX hosts 4 and 5 and clicked Check and see results.
OpsCheck quickly analyzed my VMotion configuration and told me that I had 10 incompatibilities between VMs and Hosts (see Figure 4).
Figure 4: OpsCheck has analyzed my VMotion configuration
As shown in Figure 4, OpsCheck reports on:
-
Host-specific
-
Incompatibilities between two hosts
-
VM-specific incompatibilities
-
Incompatibilities between VM’s and hosts
I clicked on the detailed report of all detected to find out why my VMs and hosts were incompatible. This opened a web browser with the OpsCheck Report, shown in Figure 5, below.
Figure 5: OpsCheck Report Results
The OpsCheck Report showed me that 12 of my VMs were checked and 8 of my VMs were incompatible. Wow – that is 75% of my VM Guests that are not going to work if they were VMotion’ed. I wouldn’t have known this otherwise. Without OpsCheck, I would have tried to do a VMotion or DRS would have used VMotion and that VMotion would have failed. That could have caused downtime for that VM Guest and, perhaps a critical application to end users.
This is the reason that you need OpsCheck, to find out if VMotion is going to work before it doesn’t work and you suffer downtime.
If I click on the Detailed Information for each of these incompatible VMs, I am taken to the vWire OpsCheck Troubleshooting Guidance for VMware VMotion (see Figure 6). This is a great guide that helps you to troubleshoot why VMotion is not going to work. I was taken directly to the reason, in my case, that VMotion was going to fail: Datastore Required by Virtual Machine Not Present on Host.
Figure 6: OpsCheck Troubleshooting Guidance for VMware VMotion
If I go back to the screen shown in Figure 5, the description for the very first incompatibility was: VM VIMA Appliance uses datastore “esx5:storage1” which is available on esx5.wiredbraincoffee.com but not on host esx4.wiredbraincoffee.com.
I went back and looked at this and, sure enough, I had created the VIMA appliance to be stored on the local datastore on ESX5 which would not be available if the VIMA Appliance was VMotion’ed to ESX4. The second line also reported that there was a CPU incompatibility between the two ESX hosts that would prevent VMotion. The OpsCheck Troubleshooting Guide told me this:
With the release of Update 2 for VI3, it is now possible to enable Enhanced vMotion Compatibility (EVC) on clusters to minimize CPU compatibility issues. As a last resort workaround, it is always possible to power off the virtual machine and perform a cold migration. For additional information, please refer to VMware KB Article 1003718 and the VMware vMotion and CPU Compatibility Guide.
CPU Enhanced VMotion Compatibility (EVC) is certainly something I need to configure to really get VMotion working between these two ESX hosts in my lab environment.
Conclusion
In conclusion, the free vWire OpsCheck tool is something that every VMware Admin should run to ensure that VMotion will really work in their VMware ESX DRS cluster or just to ensure that you can VMotion if you choose to. I encourage you to try out OpsCheck on your own VMware Virtual Infrastructure that has VMotion enabled.
