Virtuozity

The standard for Service Console (SC) RAM in ESX 3.5 server is 272MB. This minimum is fine for the standard server that does not have installed any other software. But you might have proprietary hardware agents, backup solutions or other software installed, and you might run into serious trouble you are unaware of, if do not expand the SC memory (e.g. HA agent errors). 512MB should be enough for most scenarios, but if you don't mind you can go for the maximum of 800MB. You have to configure the RAM size in the ESX configuration file

/etc/vmware/esx.conf

Just search for /boot/memSize = "272" and enter your value. After that you will have to deal with GRUB and the init process, because the settings are boot-relevant. ESX server has proprietary aliases for that, the command is esxcfg-boot. You have to run it twice: First time to regenerate the GRUB configuration files, the second time to recreate the initrd file with the new settings. You might want to use this short shell script, that does it all for you:

sed -i 's/memSize = "[0-9][0-9][0-9]"/memSize = "800"/' /etc/vmware/esx.conf
esxcfg-boot -g
esxcfg-boot -b

Because you have to reboot the host to take effect, so you should plan this for your next ESX patch day.

The VMware Update Manager is a very convenient way of updating your ESX hosts or your entire environment including VMs an their applications, but you have to configure it properly and sometimes even that is not enough. I recognized more than once, that no more updates were received for a while, but the Update Manager told me that everything was compliant although I knew it was not. So what to do?

First, please be sure NOT to use the old "VMware Infrastructure Update Client", an application which is still on your vCenter server for legacy reasons, but is definitely not the tool to update your ESX 3.5 hosts! The right way to do it, is to install the "VMware Update Manager Plugin" within your vCenter client application and activate it.

Now let us assume your Update Manager does not provide any more updates. Please uninstall the "VMware Update Manager" application and delete the remaining installation directory. Do not forget to delete the old download folder, because Update Manager keeps track of it's updates by a database and not by the files, and since we are going to reinitialize the database, you do not want any inconsistencies here. The standard path for Update Manager downloads is C:\Documents and Settings\All Users\Application Data\VMware\Data

Now you reinstall Update Manager from your ISO / DVD and enter credentials to access your proxy if you have one and the right DSN (ODBC connection). Please be sure the DSN is the correct one and that it is NOT your vCenter database, because when the installer asks if you want to reinitialize the Update Manager database, you select yes and confirm it.

After installing you open the vCenter client and check for the activated Update Manager plugin. You should have a new icon on the upper right, just click on it and configure your Update Manager properties, if you have to. Now click on "Scheduled Tasks" and you will see a now task named "VMware Update Manager Update Download". Reschedule it to suite your needs and if you want to do download the updates right now, just right-click on the task and run it.

Now let's talk about baselines: A baseline is nothing more than a list of available updates, divided into critical and non-critical updates for ESX hosts and VM guests. Update Manager compares your hosts and guests to these lists and looks for the delta. If your update repository is up to date and the delta is 0, the object is compliant. Otherwise there are one ore more updates available for the object. Please remember that you have to attach the baselines first, because NO baseline is attached after installation of Update Manager. To do that, go into the left pane and click on the object you are planning to remediate, e.g. "Hosts & Clusters" to update your whole environment. Now select the Update Manager tab in the right pane, click on "Attach Baseline" and select the ones you want to apply.

Now you should be ready to go, but remember that the first initialization could take very long because there are lots of update packages to download. Right-click on the object and first select to check for updates. Now the vcIntergrity component checks the objects for compliance. When the process is done, you are ready to remediate, again with a right-click on the object. You can remediate whole clusters because Update Manager only patches one host at a time. I strongly encourage you to test the patches in a non-productive environment first, because I experienced some cases where Update Manager continued with patching, even though something went wrong and the systems were not able to boot! So Update Manager shut down the whole cluster one by one...

If you do not want to update your Windows or Linux VMs with Update Manager, you should configure Update Manager skip those OS updates, because there are bags full of packages for these operating systems that will clog up your Internet connection. Most data centers have other methods for updating Windows and Linux, so if there is no need to do it, just don't do it. Click on the vCenter Update Manager configuration button and select "Update Downloads". On the right there is a small link named "Edit Update Downloads", where you can configure your Update Manager downloads.

If you have an Internet firewall with integrated anti-virus security, you might experience some problems downloading your update packages due to timeouts caused by the anti-virus scanning process. You can edit the vci-integrity.xml file in the Update Manager directory. Let's have a look at section downloadMgr, where you can edit

• maxDownload - How many downloads at once?
• downloadRetries - How many retries if a download fails?
• retryDelaySeconds - How many seconds to wait before retrying?
• recvTimeout - How long to wait before deciding a download has timed out?

The last entry is the one you can push up to solve the timeout problem with your firewall.

When you try to import a machine via vCenter you might get an unknown error. If you look into the log file, you will find some SSL issues and an entry like this:

[2009-02-18 10:33:59.002 'P2V' 3792 error] [task,301] Task failed: at line number 7, not well-formed (invalid token)

This problem occurs commonly in European environments and is caused by the use of Umlaute, which are quite often used in the German language. The result is the "invalid token" message. Please remove all Umlaute from all VMs in vCenter (VM Names, Folders, Notes, etc.).

Link: http://www.vmware.com/download/shared_utilities.html

Wer verschiedene Server-Typen zusammen in einem Cluster betreiben möchte und sich unsicher über deren Verhalten im Zusammenspiel ist, wird sich vermutlich über das "CPU Identification Utility" von VMware freuen. Enthalten ist ein ISO-Image zum Booten des Hosts, das Aufschluss über VMotion Kompatibilität sowie der Unterstützung bezüglich EVC und 64bit gibt.

Link: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008130

Lange hat es gedauert, jetzt ist es endlich soweit: Für den ESX-Fehler im Update Release 3 ist ein Patch verfügbar. Dieser Bug ist zwar bei den meisten Kunden gar nicht aufgefallen, die Auswirkungen wären jedoch eher dramatisch gewesen. Beim Failover im SAN wurde der Zugriff auf die LUNs vollständig blockiert, falls während des Pfadwechsels VMFS-Metadaten geschrieben wurden. Als einzige Lösung blieb ein Reboot des Hosts übrig.