January

TL;DR - In the last few days (start of 2021), the “Shields Up” feature in the Brave web browser seems to be flagging a JSON file as a cross-site tracker when creating a resource in Azure, causing the blade to not load. To work around this, you can go “shields down” for portal.azure.com. I logged on to my machine yesterday, same as any other day, and went to start deploying some resources to Azure via the Azure Portal for a customer, nothing out of the ordinary.

Yep, it’s that time of year where it seems sensible to reflect on what’s happened, and maybe set some goals for the year to come. With that said, don’t forget to keep reflecting during the year, and ground yourself to see where you are at, what you want to work on and readjust yourself if you aren’t going in the direction you hoped for. Or maybe a change in direction wasn’t what you planned, but is naturally the course you have taken due to a series of events.

Introduction Nimble Storage arrays are one of my favourite SAN arrays to work with at the moment. However, until Nimble OS3 which was made GA on the 31st of August, 2016, there was no support for the XCOPY VAAI primitive. This meant that when performing actions such as a storage vMotion that moved data between datastores on the same array, or cloning virtual machines, the ESXi host performing the action was required to read the data from the array up through the ESXi host, and then write it back to the array, creating additional load on the ESXi host and traffic on the storage adapters and network.

The post below will walk through the deployment of an embedded vCenter Server Appliance 6.5 using the GUI installer, where the PSC and VC roles are installed on the same servers. This deployment model is perfect for smaller environment where Enhanced Linked Mode is not required. The PSC Topology Decision Tree is a great read if you aren’t sure on how you should deploy these core components given your requirements.

The post below will walk through the deployment of an embedded vCenter Server Appliance (VCSA) 6.5 node to a target ESXi server using the command line interface (CLI) deployment method. If you are interested in also seeing the GUI deployment or other GUI/CLI deployments, please see my post here which has links off to other individual articles for different deployment methods. For each of the deployment methods I am providing a video as well.

The post below will walk through the deployment of an external vCenter Server Appliance (VCSA) 6.5 node and Platform Services Controller (PSC) to a target ESXi server using the command line interface (CLI) deployment method. If you are interested in also seeing the GUI deployment or other GUI/CLI deployments, please see my post here which has links off to other individual articles for different deployment methods. For each of the deployment methods I am providing a video as well.

[toc] Introduction So I’ve finally had some spare time to download and have a look at some of the vSphere 6.5 components and I’ll be planning to do a few blog posts in early 2017 on some of the cool new features that have been added in this release. I’ve decided to start with a few posts on the deployment of the vCenter Server Appliance (VCSA) using both the new GUI installer and the CLI option as well.

So last week I noticed that a user by the name of Dean had opened a thread on the Nimble Connect forums with some handy PowerCLI to configure an ESXi host to connect to Nimble Storage arrays. I had done the same thing near the end of 2015 when we installed 6 Nimble Storage arrays in our environment, and I was meant to get around to putting it all together in a powershell function/script.

I’m going through the process of installing VMWare Site Recovery Manager (SRM) 6.1 in our production environment, which is currently running vSphere 6.0U1. We use Nimble Storage arrays and have elected to make use of array based replication (ABR) for data replication between sites. During our initial testing and doing full failovers of some dev applications, I noticed that the datastore name within vCenter for the protected volume on the SAN was getting renamed, and had a prefix of snap-5b356a02-VolumeName

Recently I’ve gone through the process of replacing the machine_ssl certificates on our vCenter and PSC nodes at work, and shortly after I went to use Update Manager and received the following error: sysimage.fault.SSLCertificateError We opted for the ‘Hybrid’ model of certificates in vSphere 6, where the machine_ssl certificate on the PSC and VC server nodes is replaced with an externally signed certificate, and the VMCA takes care of all of the solution user certificates using the default configuration.