While trying to add an ssd to my esxi 5.5 server I encountered a bug when it tried to format and add the storage:
Error:A specified parameter was not correct.
Call “HostStorageSystem.ComputeDiskPartitionInfo” for object “storageSystem” on ESXi “x.x.x.x.” failed.
I found a blog post describing the same issue and found it was the existing partitions that was causing it to fail. But instead of dropping into the CLI to delete the partitions manually and continue, the comments had another idea: Create a VMFS3 partition then upgrade to VMFS5.
I ended up creating a VMFS3 partition, but deleted it instead of upgrading it. Then I created a VMFS5 partition successfully. I don’t care for upgrading filesystems. I always prefer to start fresh.
I’ve been fighting a very annoying bug with a couple of my Windows servers. They would lose their static IP address after being vmotion’d and go back to DHCP. The easy workaround was to disable DRS on those specific VMs which we did, but that doesn’t fix anything.
I thought for sure that the issue was at the VM level, but it turns out that after upgrading from 5.1 Patch 2 (1743533) to 5.1 Patch 7 (2583090) the issue has cleared up.
Here is a very useful list of all the versions and release dates from VMWare.
I ran across this little gem of a bug on VMWare’s Update Manger while trying to scan any of our hosts:
VMware Update Manager had an unknown failure: Check task and events
It was probably caused from our last upgrade. We upgraded from vCenter 5.1 on a Windows 2003 32-bit to 5.5 on Windows 2008 R2 (64-bit). VMWare’s supported helped me through the upgrade and it went smoothly. Until I had to use Update Manager. I couldn’t find anything online to help fix it so I ended up uninstalling Update Manager, re-installing it, and this time choosing to go with a blank database. Luckily, our environment is small enough that I can get away with that.
I was finally bitten by the vCenter 5.1 Single Sign On (SSO) bug. Yikes, that was bad. I had to restart the SSO service nearly everyday in order to login to vCenter. I was just leaving the vCenter Client open all the time to avoid it. Well, I finally upgraded vCenter to 5.5 to fix it, and it looks like it has so far (knock on wood).
However, in order to upgrade vCenter to 5.5 I first needed to get it off the Windows 2003 box it was on. vCenter 5.5 doesn’t support 2003. Also, I wanted to virtualize the machine. So how do I go from a physical Win2k3 box running 5.1 to a virtual Win2k8R2 box running 5.5? Actually, it’s easier than you think. (A big thank you to Murali M. at vmware. He walked me through this.)
- Build up the new VM.
- Install SQLExpress (we have a small deployment so Express is more than adequate.)
- Use SMSS to backup and restore the db’s from the old sqlexpress instance to the new one.
- Create an ODBC connection on the new server to the vCenter db.
- Do a custom install for vCenter 5.5. Install each component separately and in order: SSO, Webclient, Infrastructure. The installer will walk you thru it. Skip vCenter Server for now.
- Shut down vCenter Server service on the old server.
- Install vCenter Server on the new server and use the ODBC connection to use the restored db. This will upgrade the 5.1 db to a 5.5 db.
If anything goes wrong, just shutdown the new server, turn on the old vCenter service and we’re back.
My first plan was to just install 5.1 on the new box, migrate the db’s and then do an in-place upgrade. This new method is cleaner, simple, and quite easy.
With Mike’s excellent post, I was able to update my esxi install from Update 1 to Update 2 via the command line.
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20140902001-standard
esxcli network firewall ruleset set -e false -r httpClient
To get the list of updates:
esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml