How To KILL a stuck Virtual Machine (ESX 3.5)

Found this useful the other day - twice.

The first time a VM would not live migrate from one host to another. I stopped it and migrated but then it would not start, giving me the "Could not power on VM: No swap file. Failed to power on VM"
Using the below instruction I managed to kill the process that was still making it seem like the VM was running fine.

The second time I was taking a snapshot of a VM and it just did not work. Timed out AND made the VM freeze. I tried restarting and turning off the VM but it would not as there was "another process running" which I guess was the failed snapshot. Again, I used the below commands to kill the process (the VM) and was then able to start the VM.


ps -auxwww | grep -i


Find the PID and kill -9 pid

or

vm-support -x - to list vmids

vm-support -X to kill it

iSCSI Storage Connectivity Best Practice with VMware

I am quite impressed with VMware I must say. We use it in production at work and now I cannot imagine my professional life without it.
In this post I will briefly describe what your ideal cheap iSCSI Storage setup should look like.

Normally, production environments of many companies will use full versions of VMware ESX (e.g. ESX 3.5 - commonly;y know as VI3 Infrastructure or the new vSphere - ESX 4.0) with a SAN (Storage Area Network) where the Virtual Machines will live. In most cases the connection between the ESX boxes and the SAN is via Fiber Channel (FC) (see here for more info). This is usually very expensive.

Many companies resort to using iSCSI for their test environments or even production environments. You can learn more about iSCSI here.

Both ESX and ESXi versions support Software iSCSI Adapters. You are free to buy iSCSI HBAs but I found that the Software adapter is quite enough for all my testing needs. Money saved.

The diagram bellow shows what you ideal iSCSI network setup should be (click on it for the bigger version).


This setup requires that each ESX (ESXi) box has (at least) two NICs that will carry the data over iSCSI. Each NIC will hook into a separate Network Switches. So you will need two Network Switches too. The idea is that if one of the ESX (ESXi) NICs fails you will still have connectivity over the other NIC. And if one of the Network Switches fails you should still have connectivity to the iSCSI Storage Device.
So the single point of failure in this example is the iSCSI Storage Device (this post will not deal with that).

You can have iSCSI working with just one network sw and one NIC per ESX box but that does not give you redundancy. The above setup is good enough to use in production. I would recommend the 1 SW + 1NIC/ESX for TEST environments only.

I will probably write a more detailed tutorial on how to do the above setup with VMware ESX (ESXi) in the future.

That's it for now :)