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. This was actually easier than I had anticipated (having read posts on previous versions of vCO that involved created the loops manually).
Ready? Here we go…
Create a new workflow – I’ve called mine “DefinIT-Backup-ESXi-Config-Cluster” and open the Schema view. Drag a “ForEach” element onto the workflow and the Chooser window pops up. This is a bit deceptive at first because it’s blank! However, if you enter some search text it will bring up existing workflows, so I searched for my “DefinIT-Backup-ESXi-Config” workflow that was created in that previous post.
Backing up ESXi 5.5 host configurations with vCenter Orchestrator (vCO) – Workflow design walkthrough
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:
- Right click host to trigger
- Sync and then back up the configuration to file
- Copy the file to a datastore, creating a folder based on date and the host
Ideas for future extensions of this workflow include - trigger from cluster/datastore/host folder, email notifications, emailing the backup files and backup config before triggering a VMware Update Manager remediation. Hopefully all this will come in future posts - for now, lets get stuck into the creation of this workflow.
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
Well with the Announcements I have seen today this would seem not to be the case.
VSAN requires a minimum of 3 hosts, so lets assume for arguments sake they will have 2 CPUs each, this will mean a VSAN install will set you back around a cool £9000 (happy to be corrected if this figure is now inaccurate) before you even go ahead and procure any disks etc. That is not exactly compelling me to rush out and buy it especially given a SAN in this area of the marketplace is not far above that price including disks.
So where is the SME/SMB love VMware? I am sure they are keenly aware that 50-60% of their business is SME/SMB (in the UK at least) so I am very disappointed to see little or no offerings for this marketplace.
Perhaps this comes down to their interpretation of an SME/SMB everyone I have so far spoken to has differing opinions so perhaps this should not be a surprise?
Perhaps they had no intention to pitch it at that marketplace?
Either way I will hold out hope that a "Foundation" option appears and SME/SMB businesses alike can share in the VSAN goodness.
If you work in an SME/SMB please let me know what you think. I am personally very keen for more opinions on the subject.
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.
Below is the list of hosts and VMs running for this exercise:
- ESXi-01 - my "Protected Site" - this is running DC-01, VC-01, SRM-01 and VRA-01 (to be installed later)
- ESXi-02 - my "Recovery Site" - this is running VC-02, SRM-02 and VRA-02 (to be installed later)
- DC-01 – this is my domain controller, I’m only going to use one DC for both “sites” as I don’t have the compute resource available to have a second running. This is also my Certificate Authority.
- VC-01 – this is my primary Virtual Center server, it’s a Windows 2012 R2 server. It is managing ESXi-01.
- VC-02 – this is my “recovery site” and it’s a Virtual Center Server Appliance (VCSA). It is managing ESXi-02
- SRM-01 - “protected site” SRM server, base install of Windows Server 2012 at this point
- SRM-02 - “recovery site” SRM server, base install of Windows Server 2012 at this point
- WEB-01 - this is a really, really, basic Ubuntu web server I've deployed from a template to use for testing.
Right - without further ado, let's get stuck in!
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.
Backing up a host
Quite simply you fire up your vSphere CLI client and run the command as shown below, make sure you define a file name as well as the destination folder or it will error.
You will then be prompted for authentication to the host, assuming you input the correct credentials the firmware configuration will be saved successfully to the folder you specified.
You may notice on my example I saved the file type as .tgz, you can drill into the .tgz file and see all of the config this process saves which is kind of handy if you want to be doubly sure it did the job correctly.
Restoring a host
So now you want to restore a host from a backup you have taken, we can use the same command but with the -l switch.
Important things to note
- This action will reboot your host
- This command will want to place your host in maintenance mode so therefore you will need to evacuate any VMs on the host.
- Placing the host into maintenance mode prior to running the command will not work and it will error, the process needs to place the host in maintenance mode itself.
- If you are running a small cluster you will likely need to disable HA while you perform this action to avoid errors being generated due to the lack of available resources.
Example error below
Successful restore below
I have found this to be really handy if I wish to restore a host to a previous running config, and by example will save you having to re-enter all of your network config etc.