Computerworld - VMware's vSphere virtualization platform is known for its reliability and offers built-in features like High Availability (HA) to ensure that physical server failures have only minor effects on end-user applications. But not everyone chooses to use these features and, as with any technology, bad things can happen even if you do use them. So, what do you do when the unexpected happens -- when a virtual machine is slow or down or when an ESXi server or vCenter is unresponsive?
vSphere troubleshooting overview
As part of my preparation for the VMware Certified Advanced Professional -- Data Center Administrator certification, and throughout the process of creating my (caution: shameless plug alert) vSphere Troubleshooting course, I have spent a lot of time troubleshooting vSphere. I have intentionally broken it and then tried to fix it, sometimes with success and sometimes without.
To be successful at troubleshooting vSphere, you need to consider all the pieces that make it possible. If any of the following pieces aren't functioning, then the whole virtual infrastructure (VI) could fall apart.
• Physical servers: The servers that ESX and ESXi run on require power and have power supplies, CPUs, RAM and local disks, all of which can fail.
• Physical network: The local LAN provides critical connectivity for the physical servers, switches, SAN/NAS, DNS servers, end users and even you (the admin), when you're trying to run the vSphere client. (The client is a management tool, and it's where you'll spend 99% of your time administering vSphere.)
• Shared storage: Storage is typically provided by a SAN or a NAS and, many times, if that SAN or NAS is unresponsive or connectivity has been lost, the virtual infrastructure can be affected.
• ESX and ESXi Server Hypervisor: The "operating system" on the physical servers must, of course, be functioning and communicating. Problems will arise if the ESX or ESXi server suffers a PSOD (purple screen of death).
• vCenter: While vCenter is not required for virtual machines or ESX/ESXi servers to function, you do need it to view the status of your virtual infrastructure and to initial things like vMotions. And it, too, can fail.
• Virtual machine (VM): You could have problems if a Windows VM suffers a BSOD (blue screen of death) or is otherwise unresponsive. That VM could be supporting critical network services, such as Domain Name Services, Active Directory or vCenter, and if it goes down you could experience problems elsewhere in your infrastructure.
The methodology
Because there are so many pieces that are critical to making a VI work, you need to have a standard, systematic approach to solving problems. It's fine for different shops to have different methodologies, but it's important that, whichever approach you use, you perform the steps in the same order and in the same way every time you have a VI problem.
For example, your methodology could be based on the Open Systems Interconnection (OSI) model and you could start at the physical layer and move up to the application layer, or vice versa. Let's say that you hear about a problem that sounds like a total VI outage. I would suggest a modified approach where you start in the middle of the OSI model (the network layer) and either go up or down based on the results. For example:
• Ping ESX/ESXi servers and the vCenter server. This verifies that they have power and network connectivity. If this is unsuccessful, you can check the network and the power availability. If successful, move on to the next step. If unsuccessful, you need to check your physical servers and network to see if they have power and if you can access them from the console.
• Attempt to log in to vCenter with the vSphere client. If unsuccessful, attempt to log in to an ESX/ESXi host individually. If successful, see what you learn from the vSphere client. Is the shared storage unavailable? Has a host failed? Has the VM that the vCenter server runs on failed?
• Check vCenter processes. Assuming that vCenter is unavailable but the VM is running on a powered-on host, check vCenter processes and restart them if needed.
This is just an example of some common steps you might follow to solve problems in the VI. Let's look at a more specific example.
You are previewing premium content. 
Free Insider Guide