We had an issue the other day with our filers and because of it, some our machines orphaned themselves and VMware didn’t know what to do with them. If I tried to power off the machine I would get the error,
Basically, I don’t even think the machine was on, but my vCenter server showed it as being powered on. Luckily I found a KB article that deals with this. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014165.
SSH into the host that the VM is said to be running from. Then run the command:
esxcli vm process list
This gives you a list of all the running VMs, and the important piece you want is the World ID. Copy that, and then run the command:
esxcli vm process kill –type=[soft,hard,force] –world-id=WorldNumber
Note: Three power-off methods are available. Soft is the most graceful, hard performs an immediate shutdown, and force should be used as a last resort.
As you can see, I ran this command and it killed the VM. After doing this, I was able to power on the VM without issue. I used soft and it worked.
That’s all I have for today.
I am all signed up and ready to go!!
We have two vCenter servers that are in linked mode. After upgrading to Vsphere 5 I have been having problems deploying machines. I get this error:
Strange right… Well, I then decided to do a vStorage migration of a machine and got the same error:
Turns out that this is a bug with no fix right now when you link two vcenter servers together. To get around this, make sure that your VIC client is logging into the vCenter server that you are going to do the vStorage migration or deplate deployment from. If I have vCenter Server A and B and I want to deploy from a template on B; you would log into the B vCenter to deploy.
Here is the KB article http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2013516
Had a very strange issue last night with one of my ESXi 4.1 Update 2 hosts. In Vcenter, suddenly one of my hosts showed disconnected. I could ping the host and remote into all virtual machines on the disconnected host, but for some reason Vcenter couldn’t see it. Here were the troubleshooting steps I took yesterday.
1. I used putty to SSH into the disconnected host. I then restarted the service using the command “services.sh restart “.
2. I still could not connect the host in Vcenter. I then tried removing the host and re-adding to Vcenter. It threw an error and would not add.
3. I remoted into my Vcenter VM and tried pinging the disconnected host. The Vcenter server was unable to ping either by name or IP. What was strange is that I could ping another server at that location. If I remoted into any other machine, it could ping the disconnected host…it was only the Vcenter server that couldn’t see it. This was not dns or IP. I restarted the Vcenter server to no avail.
4. Luckily this disconnected host was on site and I was able to connect a monitor and keyboard to it. Normally I would remote in using the ILO port, but that is not configured right now (another story altogether). I restarted the management agents from here. I was now able to ping from the host and from the Vcenter server. YAY!
I don’t know why restarting the management agents from the console was any different that when I SSHed into the machine, but it was.
During our migration from ESXi 4.1 Update 2 to ESXi 5 Update 1 we decided to change all nics on VMs to VMXNET3. Everything was fine until my users came in the next morning and couldn’t do some of the things that they needed to do. It turns out that there were some programs tied to the old MAC address of the nic that I had removed from the virtual machine. We had to get licenses tied to the new MAC addresses, and then the decision was made for the remaining VMs that I still had to work on, to keep the current MAC address. How to do this…
1. Install the latest VMware tools. (If you haven’t done this, you might not see VMXNET3 as an option for network card.
2. RDP into the virtual machine and take not of the IP information on all nics. Then, change the IP to “Obtain an IP address automatically” and “Obtain DNS server address automatically”. (This keeps you from getting weird messages later about IP addresses already being assigned to a nic.
3. Shut down the VM.
4. Edit Settings on the VM using the vSphere Client.
5. Click on each network adapter and write down the current MAC address. Then click on remove to remove the nic from the machine.
6. Click “Add” and then select “Ethernet Adapter”.
7. Change the adapter type to VMXNET3 and then choose your network for the VM.
8. Change the MAC to “Manual” and then enter the MAC that you wrote down before from the old nic.
9. Click “OK” and the old nic will be removed and the new nic added. If you go back in and look at the nic you will notice that it has the MAC that you manually added.
10. After powering on your VM, open the command prompt in administrative mode and type without quotes, “set devmgr_show_nonpresent_devices=1” Then type “devmgmt.msc”
11. When device manager opens click “View –> Show Hidden Devices”. Hidden devices, especially old nic need to be removed. You will see unused devices showing greyed out. Right click on them and choose “uninstall”.
Hopefully this saves someone from a licensing headache when upgrading your VMs.
So I downloaded a trial of VMware View to see if there would be some value within our organization. First I am only testing with one Connection Server and using my existing vCenter Servers. Whenever I would deploy a pool of machine, each desktop would just say, “Confiuring” and nothing else was happening.
SOLUTION: You must install the VMware View agent on the template and then deploy from it. The agent allows for the communication between the CS and Client workstation.
I started this blog to document everyday things that I run into for my position as a VMware Administrator. Hopefully it benefits others and makes someones day a little easier.