Yellow Bricks

by Duncan Epping

Scripting

Where are my files?

· ·

I was working on an automated build procedure yesterday of ESX hosts in a cloud environment. I stored my my temporary post configuration script in /tmp/ as I have been doing since 3.0.x. When the installation was finished the host rebooted and I waited on the second reboot to occur, which is part of my post configuration. Weird thing is it never happened.

So I assumed I made a mistake and went over my script. Funny thing is it just looked fine. For troubleshooting purposes I decided to strip my script and only do a “touch /tmp/test” in the %post section to see if the file would be created or not. I also removed the “automatic reboot” after the installation. When the installation was finished I went into the console and noticed my file “test” in /tmp. So I rebooted the system and checked /tmp again…. gone. HUH?

I figured it had something to do with the installer. I installed ESX manually, including a “/tmp” partition, and booted the server. I copied a bunch of random files into /tmp and rebooted the server… again the files were deleted. Now I might be going insane, but I am pretty certain this used to work just fine in the good old days ESX 3.0.X. Apparently something changed, but what?

After some googling and emailing I discovered  that this a change in behaviour is a known issue (release notes). When ESX 4.0 is booted the “/etc/init.d/vmware” cleans out /tmp. (See below) Something you might want to take into account when using /tmp.

# Clear /tmp to create more space
if IsLocalFileSystem /tmp ; then
rm -rf /tmp/*
fi

I want to thank my colleague from VMware GSS Fintan Comyns for pointing this out.

NFS based automated installs of ESX 4

· ·

Just something I noticed today while testing an automated install from NFS. The arguments I pass to the installer are:

initrd=initrd.img mem=512m ksdevice=vmnic1 ip=192.168.1.123 netmask=255.255.255.0 gateway=192.168.1.1 ks=nfs://192.168.1.10:/nfs/install/ks.cfg quiet

Let’s focus on the part that’s incorrect, with ESX 3 the following bit(part of the bootstrap above) would work:

ks=nfs://192.168.1.10:/nfs/install/ks.cfg

As of ESX 4 this doesn’t work anymore, and when I do an “alt-f2” and go to /var/log and check the esx-installer.log file it shows the following error:

mount: 192.168.1.10::nfs/install failed, reason given by server: Permission denied

After checking the permissions on my NFS share 4 times I was pretty certain that this could not cause this issue. After trying some various combinations I noticed that the format of the string for “ks” has changed. As of ESX 4 you can’t use the second colon(:) anymore. So the correct format is:

ks=nfs://192.168.1.10/nfs/install/ks.cfg

I still receive a warning but the installer does continue. If anyone knows why the following message is displayed please speak up:

No COS NICs have been added by the user

Network loss after HA initiated failover

· ·

I had a discussion with one of my readers last week and just read this post on the VMTN community which triggered this article.

When you create a highly available environment take into account that you will need to have enough vSwitch ports available when a failover needs to occur. By default a vSwitch will be created with 56 ports and in general this is sufficient for most environments. However when two of your hosts fail in a 10 host cluster you might end up with 60 or more VMs running on a single host. If this would happen several VMs would not have a vSwitch port assigned.

The most commonly used command when creating an automated build procedure probably is:

esxcfg-vswitch -a vSwitch1

This would result in a vSwitch named “vSwitch1” with the default amount of 56 ports. Now it is just as easy to set it up with 128 ports for instance:

esxcfg-vswitch -a vSwitch1:128

Always design for a worst case scenario. Also be aware of the overhead, some ports are reserved for internal usage. You might want to factor in some additional ports for this reason as for instance in the example above you will have 120 ports available for your VMs and not the 128 you specified.

VMware vSphere Health Check Report v4.0.0 by @lamw

· ·

William Lam just released version 4 of his Health Check Report. I guess I can talk about it for hours but the sample report that William provides says more in just a few clicks than I can in 1000 words. Below you can find an outtake from the release notes. I clipped it as it was too long, but you can find the complete info here. Make sure this script is part of your standard toolkit as it will most definitely come in handy! Highly recommended.

This script generates a health check report similar to that of vmwareHealthCheckScript but for the new vSphere release of VMware ESX(i) 4.x and VMware vCenter 4.x and it’s managed entities. User’s can now fully customize the report based on the categories that are of importance to their operating environment, including selecting specific set of ESX(i) hosts and/or Virtual Machines.

The script reports on the following:

  • New Report is now completely modular in which categories to display via a configuration file
  • New Ability to specify specific ESX/ESXi host to query
  • New Ability to specify specific Virtual Mchines to query
  • New vCenter HA Advanced Runtime information
  • New vCenter HA Configuration (primary/secondary and node states)
  • New vCenter HA Advanced Configurations
  • New vCenter DRS Advanced Runtime information
  • New ESX/ESXi IP/HOSTNAME of vCenter Management IP
  • New ESX/ESXi Newly improved Hardware and System Health Stuats information
  • New ESX/ESXi Advanced Configurations
  • New ESX/ESXi NUMA information
  • New VM UUID,Bootime,Resource Statistics, Fault Tolerance, Thin provisioned and NPIV information

    • Win an Apple iPad for you and your friends!

    · ·

    This is just a reminder. The ESXi scripting contest is still running.  Make sure you enter the competition. So far not many people have so chances of winning are pretty big!

    VMware challenges you to build the best, most creative ESXi management scripts possible. The goal of the ScriptoMania contest is to help our wider community adopt ESXi by providing useful, fun and powerful scripts to manage the ESXi platform. The best part is that we give our winners bragging rights and we put some hard cold cash in your pockets. Are you up to the challenge?

    Contest Overview: