VMware has just posted an article in the Virtual Blocks blog which describes this behaviour. It happens only when trying to Storage vMotion a virtual machine with a swap file larger than 64GB to the vSAN datastore.
The task fails and generates the following error messages:
There are two possible workarounds available: either increase the swap file maximum size on the destination ESXi host or set a reservation of memory on the virtual machine. The former one is more preferable, as it does not require host reboot.
VMware provides a KB 2150316 with “more log samples and specifics for identifying the issue as a cause of a migration failure”.
Less than two months since VMware announced the availability of a vSphere beta and it has been refreshed with the new features and bugfixes. To participate in the program, candidates should indicate their interest by filling out this simple form.
I personally think time around Christmas holidays is the best one for tech geeks to dedicate some of their time and have an understanding of what’s next.
The beta refresh is available as a downloadable media and as a hosted environment in the Hands-on-Labs.
For those folks who need access to the full range of technologies from VMware, the VMware User Group has just announced a 10% discount on the VMUG Advantage subscription. This offer is available until December 31st, 2017.
All this sounds like a great Christmas gift from the vendor. Thank you, VMware!
Another day another case… This time, I was surprised to see an empty list when provisioning a new virtual machine from a Content Library.
I went to check the Content Library status and found all templates were shown as ‘Unknown’ in there.
Funny enough, this behaviour was happening only with the local Content Library. A subscribed one didn’t have any issues at all, and the synchronisation between those two was still working.
More interestingly, the objects of other types were not affected at all.
There is not enough information about how to troubleshoot the Content Library in vSphere 6.0. Some of the diagnostic files can be found in the /var/log/vmware/vdcs directory on vCenter Server Appliance (VCSA). Unfortunately, they are not that informative.
So I opened the case with VMware GSS (SR # 17504701707) and the response was that “this issue is occurring as there is a corrupted or stale PID for the content library service which has not been cleared from the previous running state.”
VMware is working on this to be resolved, but no ETA at the moment.
A workaround provided by VMware:
- Connect to the vCenter Server Appliance using SSH and root credentials.
- Navigate to /var/log/vmware/vdcs.
- Create a new folder to move the PID file to.
- Move the vmware-vdcs.pid file to the folder created in step 3.
- Reboot the vCenter Server Appliance (In case of external PSC, reboot the PSC first and then the vCenter).
I personally found that restarting VCSA resolves this issue. However, it reappears after some time.
VMware has just released a major update to vCenter Server 6.5 with a plenty of exciting features including:
- Ability to run the vCenter Server Appliance GUI and CLI installers on Microsoft Windows 2012 x64 bit, Microsoft Windows 2012 R2 x64 bit, Microsoft Windows 2016 x64 bit, and macOS Sierra
- vSAN software upgrades through integration with vSphere Update Manager
- Support for Microsoft SQL Server 2016, Microsoft SQL Server 2016 SP1, and Microsoft SQL Server 2014 SP2 as external databases for vCenter Server
- Improved HTML5-based vSphere Client
- Increased configuration maximums for the Linked vCenter Server instances
- vSphere Replication updates
- Driver updates and hips of resolved issue.
The following products have been updated:
Updated packages can be found here.
More information about new features is available following those links:
I have a few support requests with VMware GSS open, which should be resolved in this release of the product.
Will keep you posted after upgrading my environment and finishing testing.