Yellow Bricks

by Duncan Epping

3.5

Changing the IP-address of an ESX host and HA

· ·

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.

Pegasus error after installing ESX 3.5 update 1

· ·

After installing ESX 3.5 update 1 an error occurs during the boot proces:

Parsing error: parse error: Error adding class VMware_IdentityMemberOfCollection to the repository: CIM_ERR_NOT_FOUND: The requested object could not be found: “VMware_Identity”
Compiling omc-smash-interop-schema.mof into root/PG_Interop

A quick search on the VMTN forum revealed that I wasn’t the only one experiencing these problems. Luckily Mike Laspina already discovered how to fix this problem:

Here is what you will need to do.

Edit the roleauth-schema compiler directive to include the VMware_Identity class definition using nano /var/pegasus/vmware/install_queue/3_files/mofs/root/PG_Interop/roleauth-schema.mof

Add the bolded line above the pre-existing member directive.

#pragma include (“VMware_Identity.mof”)
#pragma include (“VMware_IdentityMemberOfCollection.mof”)

It also needs to be added in the standard cimv2 path.

nano /var/pegasus/vmware/install_queue/3_files/mofs/root/cimv2/roleauth-schema.mof

#pragma include (“VMware_Identity.mof”)
#pragma include (“VMware_IdentityMemberOfCollection.mof”)

Copy the missing file from the stardard cimv2 path to the shared path.

cp /var/pegasus/vmware/install_queue/3_files/mofs/root/cimv2/VMware_Identity.mof /var/pegasus/vmware/install_queue/3_files/mofs/root/PG_Interop/

Stop and start the service with these commands.

/etc/init.d/pegasus stop
/etc/init.d/pegasus start
Once the scripts completes the install_queues will be empty and the service will start much more quickly.

And according to the user mjilin VMware support is also aware and this issue will be addressed soon:

Dear ESX users,

Thanks for your timely feedback regarding upgrading to ESX/ESXi 3.5 Update 1.

As one user correctly pointed out, we use Pegasus to provide system management information, which third-party vendors can incorporate into their management applications.

We have identified the root cause of the issue and will provide fixes in an upcoming patch release. More information can be found in the Knowledge Base article 1004257.

Thanks for your information sharing in the community forum and keeping the discussion lively. We appreciate your support and feedback.

Best regards,

VMware ESX Product Tea

Swapping and/or ballooning

· ·

Today a customer called about a problem with the Exchange VM. For some reason the ESX Host where this VM resided was always swapping/ballooning. They checked and double checked the settings but could not find the problem. After a quick scan I noticed that there were limits set on memory for each VM. This particular VM had 1536MB of memory and a limit of 1024MB. After changing the setting back to it’s default setting, “unlimited”, the message was gone. I haven’t got a clue why this setup this way, limitting the memory to the exact amount assigned to a VM… weird, but problem solved.

Weird scripted install problems

· ·

Today I was testing a scripted installation for a customer. All day long I had weird problems with the script. But whenever I reviewed my script their seemed to be nothing wrong with it. I wrote the scripts with Notepad++ and double checked them with vi and nano. You can imagine I almost threw my laptop out the window of sheer frustration. Notepad++ has a function called “convert to unix format” and although I could not find any weird characters, returns of whatsoever… it did solve my problem. After having a closer look at Notepad++ it seems like there’s a setting to avoid this behaviour:

I should have known it isn’t a good idea to edit linux script files on a Windows host, if only VMware would release a linux version of the VirtualCenter client…