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.
3.5
ESXi and SSH, what’s next
I get a lot of questions about ESXi and SSH. Most people manage to connect to their ESXi but don’t know what to do next because there’s no actual Service Console there. Well the answer is short and simple: vim-cmd.
A couple examples of stuff you can do with vim-cmd:
enter maintenance mode: vim-cmd /hostsvc/maintenance_mode_enter
List all registered vm’s: vim-cmd /vmsvc/getallvms
Install VMware Tools for VM with ID: vim-cmd /vmsvc/tools.install [vmid]
Power on a specific VM: vim-cmd /vmsvc/power.on [vmid]
So check out the link above and start trying out this poweful command
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
das.allowNetwork where and when
I’ve seen a lot misinterpretations of the new advanced HA option “das.allowNetwork”. What is this option for and when should I use it or shouldn’t is the most asked question.
So let’s start with a little history, back in the days “pre 3.5 U2” one could configure a cluster on multiple IP subnets without facing any problems, but this could lead into start up or execution problems. HA would configure without checking if the network on every host was compatible with the other, but in ESX 3.5 U2 this procedure changed. As of this version during the configuration of HA the host checks it’s network for compatability with the first configured HA host. So if the first host has the following configuration:
esx01 – 192.168.1.11 – 255.255.255.0.
And the second host has the following configuration:
esx02- 192.168.2.11 – 255.255.255.0
HA will fail with the following error:
“HA Agent on <hostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Networks: Host has network(s) that don’t exist on cluster members: <ip address>: Cluster has network(s) missing on host: <ip address>: Consider using Advanced Cluster Settings das.allowNetwork to control network usage”
With the advance option “das.allowNetwork” you can rule out certain Service Consoles for HA usage. In other words, if you have several SC’s on each ESX host you can specify which SC should be used for HA. HA, as most of you probably know, uses the SC network for it’s heartbeat.
A couple of examples when to use das.allowNetwork and when not to use it:
- So what should you do to get things running when you’ve used different subnets for each host?
Well that’s an easy one… get all your Service Consoles on the same subnet. Even if’s a routable vlan, HA will just calculate the network and if the values mismatch than configuring HA will fail! - So what if I’ve got multiple SC’s and some are on different subnets but there’s at least one on each host on the same subnet with the same portgroup name?
Here’s where das.allowNetwork comes in to place, set this option in the “Advanced Option” section of the HA tab and specify which SC should be used for HA. The ones that aren’t specified will not be used.
There have been numerous people asking if this “network compatibility” check could be disabled. At this moment the answer is no and there’s now workaround at this moment. When using das.allowNetwork specify the first as “das.allowNetwork0” the second as “das.allowNetwork1” etc.
More info can be found here:
Follow Up: HA Change (isolation response)
I’ve been asking around why the default isolation response has been changed from “power off” to “leave powered on”. It seems that this is done because a lot of customers had VM’s being powered off unnecessary. This happened because the service console or physical switches weren’t setup redundant and thus caused HA to kick in. In other words, for those having complete redundancy, switches and nics, change the default back to “power off” or use the new option “Shutdown VM”.
Shutdown VM requires VMware Tools to be installed. If HA is unable to shutdown the VM within 5 minutes it will be powered down. I would prefer this option, especially when you virtualized services like Exchange, SQL, Oracle etc.