ESX and ESXi

I tested vSphere 6 quite intensively when it was in beta, but I didn’t ever upgrade my lab - basically because I need a stable environment to work on and I wasn’t sure that I could maintain that with the beta. Now 6 has been GA a while and I have a little bit of time, I have begun the lab upgrade process. You can see a bit more about my lab hardware over on my lab page.

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 Concepts and best practices in Resource Pools http://federicocinalli.com/blog/item/194-concepts-and-best-practices-in-resource-pools#.Uzre1_ldV8F Network port diagram for vSphere 6.

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.

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. The steps I want to create in this post are:

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.

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.”

Problem Fairly recently I came across this error message on one of my hosts “esx.problem.visorfs.ramdisk.full” Fallout While trying to address the issue I had the following problems when the ramdisk did indeed “fill up” PSOD (worst case happened only once in my experience) VM’s struggling to vMotion from the affected host when putting into maintenance mode. Temporary workaround A reboot of the host would clear the problem (clear out the ramdisk) for a short while but the problem will return if not addressed properly.

As a proof of concept I recently tried to virtualize OS X (Mountain Lion) - It is important to note that VMware is now licensed to do so and you can read more here. The following is an overview of the steps I followed to achieve my goal in some cases it was trial an error as I am not a regular Mac user. The Hardware As OS X requires Apple hardware to run you will have to find yourself a Mac that will install and run ESXi.

There are different schools of thought as to whether you should have SSH enabled on your hosts. VMware recommend it is disabled. With SSH disabled there is no possibility of attack, so that’s the “most secure” option. Of course in the real world there’s a balance between “most secure” and “usability” (e.g. the most secure host is powered off and physically isolated from the network, but you can’t run any workloads ).