VMware Update Manager and Scratch Partition

A couple of weeks ago I came across a similar problem as in my previous post with update manager, this was a different problem however:

I took another shot at examining the logfiles of vCenter Update Manager on the vCenter Server aiming at confirming the issue with the metadata at “C:\ProgramData\VMware\VMware Update Manager\Logs”:

Vmware-vum-server-log4cpp.log => Gives us the following error:
2012-02-17 13:52:22:279 ‘scanHost20’ 2876 INFO] [scannerImpl, 187] Scan Complete, disabling ruleset now…
[2012-02-17 13:52:22:279 ‘SetFirewallConfig’ 2876 INFO] [hostUpdateBase, 743] No changes to firewall configuration for: updateManager
[2012-02-17 13:52:22:279 ‘scanHost20’ 2876 INFO] [scannerImpl, 191] Ruleset disabled
[2012-02-17 13:52:22:280 ‘HostUpdateDepotManager’ 2876 ERROR] [scanHost20, 348] result for host: esx14.mz.local (entity: host-2872) shows error :
—–Result Begin (esx14.mz.local)—–
<esxupdate-response>
<version>1.30</version>
<error errorClass="FileIOError">
<errorCode>10</errorCode>
<errorDesc>Unable to create, write or read a file as expected.</errorDesc>
<errorDesc>Cannot create dir /var/tmp/cache/metadata1974253129: [Errno 17] File exists: ‘/var/tmp'</errorDesc>
<filename>/var/tmp/cache/metadata1974253129</filename>
<message>Cannot create dir /var/tmp/cache/metadata1974253129: [Errno 17] File exists: ‘/var/tmp'</message>
</error>
</esxupdate-response>

    —–Result End (esx14.mz.local)—–
    [2012-02-17 13:52:22:280 ‘HostUpdateDepotManager’ 2876 ERROR] [scanHost20, 392] esx update returned errors
    [2012-02-17 13:52:22:295 ‘SingleHostScanTask.SingleHostScanTask{638}’ 2876 ERROR] [singleHostScanTask, 321] SingleHostScan caught exception: esxupdate error, version: 1.30, operation:
    10: Cannot create dir /var/tmp/cache/metadata1974253129: [Errno 17] File exists: ‘/var/tmp’
    with code: 129
    [2012-02-17 13:52:22:311 ‘SingleHostScanTask.SingleHostScanTask{638}’ 2876 ERROR] [vciTaskBase, 548] Task execution has failed: integrity.fault.HostPatchESXUpdateFailure
    [2012-02-17 13:52:22:313 ‘ChainedTaskContainer.ChainedTaskContainer{637}’ 2876 INFO] [vciTaskBase, 579] A subTask finished: SingleHostScanTask{638}

It shows an issue with creating directories and files.

One of solutions was removing the scratch partition data, but it shows that /var/tmp is not accessible.

SNAG--2012-02-17-14.07.25_thumb1

It’s a symbolic link to the “scratch partition”.

SNAG--2012-02-17-14.07.46_thumb1

I found the following articles which applied to our situation:

http://blogs.vmware.com/esxi/2011/04/scratch-partition-best-practices-for-usbsd-booted-esxi.html

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

For ESXi it is recommended, but not required, to have a persistent scratch location available for storing temporary data including logs, diagnostic information and system swap.

When the scratch partition is not available, ESXi stores this temporary data on a ramdisk, which is constrained in space and will result in the situation described above.

I performed the following actions using the vSphere client to create a scratch partition

1. Create a Scratch Partition location using the Datastore Browser on another location (I picked the ISO-STORE for it) and create a “.locker-<Hostname>” directory where you point the scratch partition to.

scratch_partition1_thumb[1]

2. Using the host advanced settings under software select ScratchConfig and edit the location of the ScratchConfig using the ScratchConfig.ConfiguredScratchLocation using the location you created in the previous step.

scratchpartition_2_thumb[2]

3.To effectuate the new scratch partition, put the host in maintenance mode and do a reboot.

VMware Update Manager shows “unknown” compliance status before the relocation of the scratch partition:

SNAG--2012-02-17-12.49.38_thumb1

VMware Update Manager after applying the scratch partition best practice:

patches_goed_thumb[1]

The unknown compliance status is gone now and it shows the real statuses.

installing_thumb[1]

After applying a persistent scratch partition the installation of patches ends successfully!

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.