Lack of disk space? 4.0 to 4.1U1 with Update Manager

[birdson]

I've searched, and read, and I can't get a definitive answer for how much disk space is required to perform the update from 4.0 to 4.1U1 through Update Manager.

On my host I get this:

[root@hostname ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sds1              39G  1.8G   35G   5% /
/dev/sdp1             1.1G   75M  952M   8% /boot
/dev/sds2             4.9G  200M  4.4G   5% /var/log
[root@hostname ~]# vdf -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sds1              39G  1.8G   35G   5% /
/dev/sdp1             1.1G   75M  952M   8% /boot
/dev/sds2             4.9G  200M  4.4G   5% /var/log
/vmfs/devices         1.0T     0  1.0T   0% /vmfs/devices
/vmfs/volumes/4c222032-e21cc2f8-8b10-a4badb20ec73
                      134G   45G   89G  33% /vmfs/volumes/jefferson_local

Is 89Gb not enough? Is there some issue with disk space reporting during the upgrade that causes it to fail? I could truly use some insight.

Happy Friday!

Birdson

[Troy_Clavell]

I don't see space being an issue.  What type of error are you getting from VUM?  Also, when you get this error, what are you trying to do?  How are you doing the upgrade, as a patch baseline or a host upgrade?  What version of vCenter are you running?

You are using ESX, correct?

[birdson]

I am doing an Upgrade Baseline. vCenter 4.1.0 Build 258902.

"FULL" ESX

Sequence of events is as follows:

Select Host, click remediate, choose upgrade baselines from Groups and types, choose my baseline, next.

Accept the terms and license agreement, next

COS VMDK set to local

Rollback Yes

Post script No

next

Run immediately, next

disable, disable, disable, next

Finish

Remediate Entity event appears jumps to 62%

Reconfigure Cluster event 1 second later (Taking host out of HA)

Enter Maintenance Mode event 17 seconds later (I have already vMotioned all VMs anyway)

Exit Maintenance Mode event 22 seconds later

Reconfigure Cluster event about 1 minute later

Remediate Entity event has Status "The selected Datastore has insufficient free space needed for upgrade. Unable to determine how much free space is required."

View Details... link gives an identical statement with the additional information of my host name, vCenter Server name and the start time of the event...

I'm going to run it again and force the selection of the local datastore... God only knows why that just occurred to me to try.

[birdson]

Nope, same results...

[dougdavis22]

Updates from VUM are copied to somewhere within the local filesystem before being executed - it's either /var or /etc somewhere, I forget now exactly where.

To see what's happening, try staging the upgrade to the host first whilst watching the output of df -h on the host itself.  My guess is that you'll see one of the local filesystems start to fill and it won't be using the 89GB you have free on the VMFS.

Doug.

[birdson]

I tried that, with the result being that no information was gained.

What I mean is,

1. I don't seem to be able to "stage" an upgrade. Patches, yes, but not upgrades.

2. I ran the remediate job again while watching df -h output on the host, the usage information never changed during the process and of course the process ran exactly as described above.

Your idea did make me think that perhaps the remediation script checks the disk space available at its target before the copy starts. When it fails this test the process aborts. Sounds good anyway, I'll do some research. Also, I would suspect that there is a log file somewhere of the actions taken by the remediation script. I'll see if I can determine where that is if it exists.

It further occurs to me that this cannot be a unique situation. I'm using common servers, Dell R710s, with a standard default install of ESX 4.0. I didn't customize the installation in any way. Therefore, I would suspect that I am not the only VUM user to have this occur.

[nkrishnan]

Hi,

did you make sure that base line has comes in Non-complaint status after you scan the base line against Cluster or host.

Could you collect the esxupdate.log and update manager logs and upload to tread. also what is the Update Manager are you using. Try to do the remediation after upgrading the Update manager to 4.1Update01

[jmichna]

I am getting the same error when I try to upgrade.  I modified the esxupdate.conf file to point to a vmfs share that had plenty of space.  Still the same error.

I am using the cli esxupdate utility right now to update the servers.

[nkrishnan]

Could you please upload the logs and steps that you followed including the ZIP bundle details.

or upload vm-support

[AnthonyF2011101]

Was a resolution ever found to this issue as i cant seem to find an answer - only people asking about the same problem - which im also now experiencing.

[AvramW]

Similar question - I'm having the same issue, but keep coming across people who have had the issue, but no resolutions.

[AvramW]

Not wanting to be one of those guys who asks, finds an answer, and then doesn't share.....

http://www.jerryblogger.com/2010/12/upgrade-esx-4-update-2-to-esx-41.html

I followed these instructions (found on another web page I think, but same instructions).  I had to clear out my /tmp/updatecache to have enough space on my / partition.  But then I was able to:

* Use WinSCP to transfer the two ZIP files (pre-upgrade and upgrade) to the host /tmp folder

* put the host in Maintenance Mode

* sudo esxupdate update --bundle=/tmp/pre-upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip

* sudo esxupdate update --bundle=/tmp/upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip

* I did not appear to have any issues with the RPM it cannot remove.  I did have issues where it could not run a script after, which caused me concern.  However, I rebooted the host and all seems to be fine.  It and the cluster are back in HA/DRS mode, and operating just fine and are now upgraded to v4.1U1.

Note, there are 5 patches currently post v4.1U1 upgrade - so do another Update Manager scan and get those done before you take the host out of maintenance mode.

[AnthonyF2011101]

This doesnt actually fix the problem does it though, this is just another way of updating the version. You may as well have replied with "download the ISO file and install over the top" as that would also upgrade things.

Has anyone actually had a resolution to this problem from VMWare so that things can be upgraded using the Update Manager as its intended to be able to be done?