So recently I came across an error in the vSphere windows “fat client” when trying to use the search field. So a quick look at the VMware knowledge base brought up the following article http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2063020 So I went ahead and followed the KB artricle and then tried to search again.. the following error was generated. Also while logging into the vSphere web client the following error appears.
Recently I encountered this problem in a customer site whereby the logon to VCSA 5.5 would either time out, or take 3-5 minutes to actually log on. Running a netstat on the VCSA during the attempt to logon showed there was a SYN packet sent to the vCOps appliance on port 443 that never established a connection. Another check was attempting to connect using curl <https://> –k - this would time out.
I recently got my hands on a copy* of Chris Wahl and Steve Pantol’s Networking for VMware Administrators and was very keen to read it – especially given the reputation of the authors. I came to the book as someone who is at CCNA level (although now expired) and someone who regularly designs complex VMware networks using standard and distributed switches. I would class myself as having a fairly decent understanding of networking, though not a networking specialist.
Extending a vCenter Orchestrator (vCO) Workflow with ForEach – Backing up all ESXi hosts in a Cluster
In my previous post Backing up ESXi 5.5 host configurations with vCenter Orchestrator (vCO) – Workflow design walkthrough I showed how to create a workflow to back up host configurations, but it was limited to one host at a time. For this post I’m going to show how to create a new workflow that calls the previous one on multiple hosts using a ForEach loop to run it against each one.
Unless you have been sleeping under a rock you will be aware that VSAN was launched last week and has gone GA today and from what I have seen so far I do think VSAN is a great product and I think VMware have done a superb job with it. Aside from the -many- discussions on twitter and other channels regarding the then lack of licensing information and pricing I was eager to see if VMware would offer a “foundation” VSAN option for SMB/SME
There are many ways to tackle the problem of quickly redeploying or recovering ESXi hosts, Host profiles, Auto deploy etc.. however such options are either out of reach for SME/SMB users where their license does not cover such features or they have very small clusters of which Auto deploy etc would perhaps be considered overkill. So how can we backup the config of our ESXi hosts? There is a great command you can use in vSphere CLI “vicfg-cfgbackup.
This had me scratching my head, what seemed to be a common problem wasn’t fixed by the common solution. It was actually my fault – too familiar with the product and setting things up too quickly to test. I installed a VCSA 5.5 instance in my lab as a secondary site for some testing and during the process found I couldn’t log on to the web client – it failed with the error:
After having a play with Virtual Flash and Host Caching on one of my lab hosts I wanted to re-use the SSD drive, but couldn’t seem to get vFlash to release the drive. I disabled flash usage on all VMs and disabled the Host Cache, then went to the Virtual Flash Resource Management page to click the “Remove All” button. That failed with errors: “Host’s virtual flash resource is inaccessible.
In my post yesterday (vexpert.me/hS) I talked about how to recover from an expired default SSO administrator password – this prompted a discussion on twitter with Anthony Spiteri (@anthonyspiteri) and Grant Orchard (@grantorchard) about the defaults for expiration and how to mitigate the risk. The first solution is to modify the password expiration policy for SSO. I’m not advocating this necessarily – I think that expiring passwords ensure that you change them regularly and increase the overall security of your SSO solution.
Today I found out that in vSphere 5.1 the SSO administrator account ([email protected]) has a password that expires after 365 days. See KB2035864: vCenter Single Sign-On account (SSO) passwords expire after 365 days, including the password for [email protected] Awesome. In vSphere 5.5 it gets even better – the password expires every 90 days by default! (See the vSphere 5.5 SSO documentation) By default, vCenter Single Sign-On passwords, including the password for [email protected]