So I came across a very odd vCenter bug today when trying to deploy an OVA file on vSphere 6.0, specifically the latest CoreOS image.
The import was repeatedly failing with the same error message.
What was more frustrating was the fact that the error message was “The task was cancelled by a user”, which it blatantly was not!
Error log example below:
OVA Import Errors
A quick bit of testing and Googling and I came across an article by my good friend Ather Beg from the LonVMUG, who had a very simple fix for the same issue in vSphere 5.5.
- Install 7-zip or a similar archiving tool
- Extract the OVA file using 7-zip into its component parts
- Import into vCenter, selecting the OVF file for the import target
That’s it – simples!
What’s really weird is that after importing the OVF successfully, I then went back and imported the OVA, and it worked fine!
Very strange indeed…
, Ather Beg
, Quick Fix
, vSphere 6
Today I came across the following propertyCollector error message whilst trying to modify the VM Swapfile location for two hosts in my lab cluster. This pops up as soon as you select the Virtual Machine Swapfile Location settings under the Configuration tab for your host. Once you click Close, you then see Swapfile Location: as Getting Data… for an infinite period of time, and the Edit… option becomes greyed out and cannot be selected.
The same error occurred on both an ESX and ESXi host in the came cluster, both using the latest vSphere 4.1 build 582267. I am going to assume this can appear on older versions too.
The object has already been deleted or has not been completely created
Call "PropertyCollector.RetrieveContents" for object "propertyCollector" on vCenter Server "<servername>" failed.
You can see the error in the following screenshot:
This seems to occur because the host does not have any record, even a default, for the snapshot location. This only affected half the hosts in my cluster, where the other half were showing their defaults just fine.
The fix for this is very simple. I’m sure it could be implemented by multiple methods, but I used PowerCLI. Simply:
- Connect to the faulty host, e.g.:
Connect-VIServer <servername / ip>
- Validate that you can see your preferred datastore from that host:
- Manually set the datastore to your preferred DS:
Set-VMHost -VMSwapfileDatastore <datastorename>
- Go back to vCenter and you will find the new value reflected, and you can now edit the Virtual Machine Swapfile Location settings under the Configuration tab for your host:
If you have multiple hosts with the same issue, or indeed when simply making swapfile location changes across your cluster, you could of course script the above.
I’m not sure whether this applies to vSphere 5 as I have not come across it there to date.