SSH to your host, grab the version –
esxcli system version get
Download the latest patch and upload to the datastore. Find the profile list –
esxcli software sources profile list –depot /vmfs/volumes/datastore1/patches/ESXi600-201711001.zip
(change path as appropriate)
Assuming your profile list shows (this is an example) –
Name Vendor Acceptance Level
——————————– ———— —————-
ESXi-6.0.0-20171101001s-standard VMware, Inc. PartnerSupported
ESXi-6.0.0-20171101001s-no-tools VMware, Inc. PartnerSupported
ESXi-6.0.0-20171104001-no-tools VMware, Inc. PartnerSupported
ESXi-6.0.0-20171104001-standard VMware, Inc. PartnerSupported
Dry run –
esxcli software profile update –depot=/vmfs/volumes/datastore1/patches/ESXi600-201711001.zip –dry-run –profile=ESXi-6.0.0-20171104001-standard
Live patch –
esxcli software profile update –depot=/vmfs/volumes/datastore1/patches/ESXi600-201711001.zip –profile=ESXi-6.0.0-20171104001-standard
You can tail the log in another ssh session –
tail -f /var/log/esxupdate.log
Once complete, reboot –
I’ve only had 1 problem with a large file filling up the datastore, so make sure you use ‘df -h’ commands if you experience any problems.
I have been monitoring a growing thin provisioned LUN for some time trying to find the cause of the growth and why we never see the LUN reduce in size. I have been running some Veeam jobs for replication and noticed that when I changed the destination datastore for these replicated machines to the thin LUN, that volume would continue to grow and never reduce in size. I suspect the 2 snapshots (restore points) are the cause of the growth, since when I check on my vsphere client in Storage view on that LUN, the total snapshot space is about the same size as the growth each night when the job runs.
To remedy this, I migrated all of the critical machines onto another LUN. I then SSH’d onto one of the hosts and cd’d into the ‘/vmfs/volumes/’ directory –
If you type ‘ls’ you will see all of the datastores attached to this host and you should see the name of the volume in question. Once you change directory into that folder you will actually go into the name of the folder (some symbolic link in place). We need to reclaim the space used on this LUN and we can do that with the unmap command.
esxcli storage vmfs unmap -u xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxxxxxx
You will see a higher iops load but monitoring the host and other volumes I am not seeing much difference in load. All the VM’s located on the LUN I am reclaiming the space from are running fine, but since I am reclaiming TB’s of space, it is taking a while!
Here are my instructions for ESXI5.5 and VM Version vmx-10
I tried instructions on http://ogris.de/vmware/freebsd10.html but it choked on line 9 with an error. I assume this was instructions for 10.0 only. When manually trying to install them it failed because it could not find perl. I basically changed every reference to perl and then it worked.
Right click the VM and guest, install vmware tools to mount the iso. If you are using web client, right click the VM, All vCenter Actions, Guest OS, Install vmware tools.
On the machine, mount the iso –
mount -t cd9660 /dev/cd0 /mnt
tar xzf /mnt/vmware-freebsd-tools.tar.gz or if you want to see it –
tar vxzf /mnt/vmware-freebsd-tools.tar.gz
grep -r “/usr/bin/perl” *
Change all references from /usr/bin/perl –> /usr/local/bin/perl
vi /usr/local/bin/vmware-uninstall-tools.pl (again change to /usr/local/bin/perl)
Now you can run the script –
You should not get an error (hopefully!!).