A new hobby I just started is 3D printing…and I gotta say it’s amazing! I bought myself a Original Prusa i3 MK3S kit which arrived last week and after a few days building, got straight into the printing. It was incredibly easy to calibrate the printer…and after a couple test prints using some of the provided models I decided to head to thingiverse and have a go at building a custom model…the Baby Yoda.
Continue reading “3D Printing – Baby Yoda”
So heaps has happened in my home lab over the past 18 months, where not only am I now running ESXi 6.7 U3, I also have an extra host with the same specs as the first, with both now acting in a 2-Node vSAN configuration.
Continue reading “vSphere 6.7 Home Lab – Part 2 – vSAN 6.7 U3 2-Node Hardware”
When attempting to install a new vRA vSphere Proxy Agent whilst on a customer engagement, I encountered the below error when testing the connection to the Manager Server Host and Model manager Web Service Host VIPs during the Install Proxy Agent wizard:
“Cannot validate Manager Service host. The remote certificate is invalid according to the validation procedure.”
Continue reading ““Cannot validate Manager Service host. The remote certificate is invalid according to the validation procedure” error when installing vSphere Proxy Agent”
So after many years putting it off I have decided to invest in building a decent home lab for testing basically everything VMware related. I spent the past few weeks researching the parts I should get and in the end, and after some help from my colleagues Tai Ratcliff and Askar Kopbayev, I finally settled on the Super Micro X10SDV-6C-TLN4F-O Motherboard as my starting point, as it can hold up to 128 GB RAM (Which is going to be important when spinning up all of the vRealize Suite).
Continue reading “vSphere 6.7 Home Lab – Part 1 – The Parts and Build”
Had a tricky issue with the vSAN Health check plugin recently, where a warning was reporting issues with some hosts not contributing vSAN performance stats.
Continue reading “vSAN Health Check – All hosts contributing stats warning”
Interesting problem we encountered on a recent project using Auto Deploy and stateful caching where the ESXi images just wouldn’t stick (i.e install) onto local disk. Using vCenter 6.5e and ESXi 6.5d, the auto deploy boot would work fine, however the install would not persist to local disk.
Seems it is a problem with the host profile being used for the Auto Deploy rule…so to workaround the issue what we did was create a seperate host profile just for the initial boot of the server with auto deploy (i.e. the host profile listed in the Auto Deploy rule), with everything unchecked in the profile except for “System Image Cache Configuration” as shown in the below image:
Once it was booted and added into vCenter, a seperate profile was then applied to configure the remaining VDS settings, Advanced Properties etc.
So I encountered an interesting problem the other week when upgrading a customer’s vROps environment from version 6.0.2 to 6.4. During the upgrade process, it appears as though the existing Python Action adapter instances were not automatically updated to the new vCenter adapters action setting, that changed in version 6.3.
What I found is when trying to manually “Enable” Actions within the vCenter adapter (under Manage Solution) I would get the following error: “Failed to create AI resource. Resource with same key already exists.”:
After reaching out to the team internally, I found that this is due to the original python actions adapter still existing even after the upgrades, so the solution was to manually remove it. As the python actions adapter was originally a Solutions adapter, and post-6.3 the “Python Actions Adapter” solution no longer exists, this meant to remove it I needed to use the REST API.
There is already a KB article detailing how to do this found here, however when attempting to run the curl command on the vROps master node appliance, it resulted in a strange error:
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
After some searching I came across this post, which then pointed me to a curl bug (which in this case was with ubuntu) that seemed to be related to the issue I was having.
So I tried to run the same curl command with a more up to date version of curl (> 7.40) and it worked perfectly, and I was then able to remove the old python action adapter instances, following by then successfully selecting “Enable Actions”.
Hopefully this helps someone else!