About a month ago I got an email about problems with upgrading VMware tools on a Linux VM. When upgrading VMware tools all modifications done in /etc/fstab after the VMware tools section would be deleted. I never got the chance to actually test it myself but now a KB article popped up and confirmed the bug. Apparently the engineers are working on it so expect a fix/update in the near future. Michael Wilmsen of Wilmsen Automatisering pointed me out to this bug.
Bugs
Starting VM’s problem with 3.5 U2
As everyone probably already knows by now there’s a problem with 3.5 U2. VMware is working on a patch as we speak. There has been a KB article released, but it seems like everyone is clicking on the same link at the same moment cause it’s hard to get a decent respond.
The error message that appears:
This product has expired. Be sure that your host machine’s date and time are set correctly.
There is a more recent version available at the VMware web site: http://www.vmware.com/info?id=4.
————–
Module License Power on failed
In short, the workaround is simple just set the date back and you will be able to power on the VM’s again, it would be smart to set the time to correct value again as soon as you started the VM. As soon as I know more about the new 3.5 U2 update I’ll let you guys know!
And a nice work around from the VMTN forum:
Find the host where a VM is located
run ‘ vmware-cmd -l ‘ to list the vms.
issue the commands:
service ntpd stop
date -s 08/01/2008
vmware-cmd /vmfs/volumes/vm path/vmname.vmx start
service ntpd start
Health status not showing..
I’ve seen this one on the VMTN forum a couple of times. When the Health Status isn’t showing you could do the following to fix it:
- Restart VirtualCenter service on the VC Server
- Restart mgmt-vmware service on the hosts that are affected (service mgmt-vmware restart)
- Restart vmware-vpxa on the hosts that are affected (service vmware-vpxa restart)
If the above did not fix the issue:
- Disconnect the affected Host from Inventory on VC
- Reconnect the affected Host from Inventory on VC
And if that doesn’t work this is also a possible solution:
- Restart the Pegasus service (service pegasus restart)
Swapping, esxtop and /proc/vmware/sched/mem
At a customer site we noticed that the ESX hosts were swapping, Nagios generated a nice alarm. After some research it seemed like certain VM’s were swapping to the VMFS volume, so not inside the OS but VMware swap usage. A closer look at the system revealed that we weren’t overcommitting. There was over 6GB of memory free and there were no limit’s set to the specific VM. Could it be just Nagios or… No, esxtop with the following commands “s2
The column swcur displays the current swap file usage, I marked the values higher than 0 red.
After a couple of searches it seemed that there is little info about swcur. But Kit Colbert, a VMware employee, posted on the vmtn forum about checking your current memory / swap usage in the file “/proc/vmware/sched/mem”. With cat you can easily display this, and with “watch -n 1” you can refresh your view every second. The following output was retrieved via the command “watch -n 1 cat /proc/vmware/sched/mem”:
We’ve migrated a VM which was swapping according to esxtop and nagios to another host, and as expected the swap remained. We powered down a VM that was swapping, and although the host had more than enough free mem available, the swap returned. It was less than before but still… The funny thing is that according to Kit it’s all about the column “swap out” and we did not see much action going on there.
I’m dazzled, anyone?
Customization spec fails part II
A while back I blogged about the customization specification wizard failing when entering the password. Today I visited the same customer again. This problem only occurred when running it from the VirtualCenter itself. Today I upgraded the VirtualCenter server to 2.5 Update 1 and the problem is solved… Still don’t know why it happened,