One of the things that never fails to amaze me are the superb PDF diagrams I occasionally stumble upon so i thought it would be a useful idea to list some of the the ones I have found on my travels.

vSphere 6 ESXTOP quick Overview for Troubleshooting

http://www.running-system.com/images/2015/04/ESXTOP_vSphere6.pdf

VMware vSphere 5 Memory Management and Monitoring diagram

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2017642

Recently I have had the pleasure to use PernixData but I did come across a bit of a ‘gotcha’ after uninstalling it from my hosts.

If like me you use iSCSI then you will likely spend a bit of time setting up your Path Selection Polices to suit your specific needs, so it was interesting to note the following.

When you do uninstall and remove PernixData from your hosts your Path Selection Polices do not revert back to your original configuration rather they revert back to the default vSphere setting of MRU (Most recently used).

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. This was actually easier than I had anticipated (having read posts on previous versions of vCO that involved created the loops manually).

As a little learning project, I thought I’d take on Simon’s previous post about backing up ESXi configurations and extend it to vCenter Orchestrator (vCO), and document how I go about building up a workflow. I’m learning more and more about vCO all the time, but I found it has a really steep entry point, and finding use cases is hard if you haven’t explored capabilities.

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

I’ve been playing about with a compact SRM install in my lab - since I have limited resources and only one site I wanted to create a run-through for anyone learning SRM to be able to do it in their own lab too. I am creating two sites on the same IP subnet (pretend it’s a stretched LAN across two sites) and will be protecting a single, tiny Linux web server using vSphere Replication. I’m aiming to cover SAN based replication in a later post.

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.pl”, which when used with certain switches can either back up or restore your ESXi host config.

I’m fairly new to SRM, but even so this one seemed like a real head-scratcher! If you happen to be using CA signed certificates on your “protected site” vCenter and “recovery site” vCenter servers, when you come to linking the two SRM sites you encounter SSLHandShake errors – basically SRM assumes you want to use certificates for authentication because you’re using signed certificates. If you use the default self-signed certificates, SRM will default to using password authentication (see SRM Authentication). Where the process fails is during the “configure connection” stage, if either one of your vCenter servers does not have CA signed and the other does (throws an error that they are using different authentication methods) or that you are using self-signed certificates for either SRM installation (throws an error that the certificate or CA could not be trusted).

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:

Since the keynote by Frank Denneman at the LonVMUG many months ago the PernixData product has been something I wanted to test to see what benefits it may or may not bring to our SQL environment, I did have the good fortune to briefly beta test it last year but this blog post will cover the current full version (FVP 1.0.2.0). I am aware that 1.5 is just around the corner and with it comes full support for vSphere 5.5 whereas the current version that I will be installing supports ESXi hosts on 5.0 or 5.1 and vCenter 5.5 (not mentioned in the minimum requirements)