Every time I think of something I want to do with RES Wisdom, I’m amazed at how easy it is to accomplish. For this example, the flow chart was more complicated to create than the actual Run Book.
What I wanted to do for this blog was create a Run Book that involved virtual machines. I thought of this very usable (I hope ;-) example in words:
– Create a Snapshot of a specific VM
– Implement changes to/in VM (e.g. Install SP2 on 2003 Server)
– If changes fail: revert to Snapshot
– Delete Snapshot
So, if a change to a VM fails, the machine is as “clean” as before!
Creating a flowchart from the words above resulted in this:
To build this Run Book I first created a Job to create a snapshot.
To make the Run Book easy to maintain and exchange (using Building Blocks), I used parameters for the server, the security context and the VM name.
On the Actions tab I selected “Create” and used a parameter for the Snapshot name.
In the same way, I created one job to revert the VM to the snapshot, and another job to delete the snapshot.
Then I created a Job to implement the change within the VM. For testing purposes the job I created was a changed the state of a service.
And, of course, I used a parameter for the service name so I could provide an existing (EventLog) or non existing (whatever) servicename.
When creating the Run Book I simply added the jobs in the right order.
Since Wisdom runs through all jobs sequentially and by default exits the sequence on error, I only had to do two things:
1) Continue Run Book on error on the “Implement Change” Job:
2) Set a condition on the “Revert” Job with “Status of previously executed Job = Failed”. When this is True; “Execute this job”. When it’s false; “Skip this job”:
After doing this I AutoCreated and AutoLinked the parameters. Since the ESX host probably won’t change in the same environment I gave it a value and untagged the “Input new value when scheduling Job”. The snapshot only exists within the Run Book, so I gave this a value as well; Wisdom@[GUID]. The last parameter I prefilled was the SecurityContext, which also won’t change too often. The only two parameters you’ll need to provide are the names of the VM and the service.
The really cool thing is, when the change fails (e.g. provide a service name that does not exist) Snapshot Intelligence kicks in because it notices a revert to snapshot. On the SI tab you can see the Job that failed so you can adjust it.
To create this Run Book for an ESX(i) server is very easy, since RES Wisdom 2009 natively supports this VMware version. However, I’ve tried it using VMware Workstation’s VMrun command and this works just as good.
I’m convinced the same can be achieved for both XenServer and Hyper-V.
Your best bet would be to look at the PowerShell options for both hypervisors.
Now the only thing to watch out for is that, while scheduling the Run Book, you select the same machine to create the snapshot from as the VM you implement the change in (I’m talking from experience ;-).