by Duncan Epping
Duncan Epping · ·
This has got nothing to do with virtualization… this is about the Dutch Soccer Squad.
WHAT IS GOING ON? First we beat the Italians with 3 -0, and yesterday we’ve beaten France with 4-1. It’s been a very long time that I actually enjoyed watching the Dutch squad. Especially the game against Italy was amazing! And what the 3-1 and the 4-1 against France… damn, what an amazing goals.
So for all the Euro’s reading this blog, let me know which country you support!
Duncan Epping · ·
Just installed the MGE Network Shutdown Module and followed their guidelines described in the following PDF. But when I started the service their was no contact with the UPS:
——————————————————————-
Network Shutdown Module
Communication with Network Management Card/Proxy has failed
——————————————————————-
When we checked the UPS logs it complained about port 5000. After enabling port 5000 in and out the connection was restored:
[root@esx1 /tmp]# esxcfg-firewall -o 5000,tcp,in,MGE-IN
[root@esx1 /tmp]# esxcfg-firewall -o 5000,tcp,out,MGE-OUT[root@esx1 /tmp]# service mge-nsm restart
——————————————————————-
Network Shutdown Module
Communication with Network Management Card/Proxy is restored
——————————————————————-
Duncan Epping · ·
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,
Duncan Epping · ·
I just encountered the same bug that Aaron Delp blogged about in January:
It appears we have found a possible bug in the Deploy from Template Command in ESX 3.5. When you create a Windows Server based template and then try to deploy directly into an Active Directory with customization, the new system will get an error that a service failed to start when the machine is launched. This is because the VMWare BootRun service is not removing itself properly after deployment. This does not happen with deployments into a workgroup.
If you aren’t familiar with the BootRun service, this service will make all of the customizations after the sysprep work is complete during the deployment. You usually never see it because it runs on the first boot, makes the changes, and then removes itself from the machine.
In this case, the files are removed but the service entry is still there, hence the error that it can’t start up. VMWare has confirmed this to be a problem and they are investigating.
This customer runs the latest and greatest version of ESX and VirtualCenter so it appears that the bug hasn’t been fixed yet.
Duncan Epping · ·
Monday evening a colleague changed the ip-address of three VMware ESX hosts. He followed the standard VMware procedure, which usually works like a charm. In this case after the ip-address was changed HA did not work anymore. Disabling and enabling the HA resulted in the following error: “Configuration of host IP address is inconsistent on host …”
After a close inspection the following error was found in /var/log/vmware/vpx-rupgrade.log:
VMwareerrortext=ft_gethostbyname and hostname -i return different addresses: 10.21.10.81, 10.21.5.12 and 10.21.1.21
The command “hostname -i” resulted in the following:
[root@bla-01 /var/log/vmware]# hostname -i
10.21.1.21
The command “ft_gethostbyname” returned the following:
[root@bla-01 /opt/vmware/aam/bin]# ./ft_gethostbyname
10.21.10.81 bla-01
10.21.5.12 bla-01
So for some reason ESX resolved the wrong address. The hosts file wasn’t the problem, but FT_HOSTS which is automatically generated by the AAM Client(High Availability) was:
[root@bla-01 /etc]# more FT_HOSTS
# Auto-generated FT_HOSTS file. Timestamp: Mon Jun 2 19:05:09 2008
10.21.10.81 bla-01
10.21.5.12 bla-01
10.21.10.82 bla-02
10.21.5.14 bla-02
10.21.10.83 bla-03
10.21.5.16 bla-03
So I moved the FT_HOSTS to FT_HOSTS.BAK:
[root@bla-01 /etc]# mv FT_HOSTS FT_HOSTS.BAK
Reconfigured the cluster for HA and everything works like expected again:
[root@bla-01 /etc]# more FT_HOSTS
# Auto-generated FT_HOSTS file. Timestamp: Wed Jun 4 10:39:52 2008
10.21.1.21 bla-01
10.21.5.12 bla-01
10.21.1.22 bla-02
10.21.5.14 bla-02
10.21.1.23 bla-03
10.21.5.16 bla-03
Deleting the cluster, removing the hosts from the cluster and or reconfiguring HA did not once update the FT_HOSTS file. I would expect that with every “reconfigure for HA” action an update or check of the FT_HOSTS file would be done.