Rapid Test Environments – Supporting automation processes in your guest virtual machines

Over the past few days I have come across multiple instances where users have wanted to run processes/commands within guest virtual machines in a software test lab environment. The ability to run these commands/processes provides immense flexibility to test and QA and makes rapid test environment creation easy and with minimal/no manual intervention.

The current limitations and customer problems

First, let me start with a couple of links and instances of what customers have been trying to do to provide you with some context. It just so happens that in these cases customers have been trying to achieve this with VMware Lab Manager and have failed to achieve success.

• This is an example of a customer posting on the VMware Lab Manager forum requesting for help to run processes in guest VMs. In this case, the customer would like to bring up a VM, install software on the VM, run some tests and bring down the VM once the test is complete. Clearly, the customer is facing some difficulty achieving this.
• I believe the customer has tried to post this question elsewhere and has limited luck in getting a truly native Lab Manager solution. The SOAP APIs provided do not help him run guest VM operations.
• Yesterday we met an ISV customer who has a dynamic build and test environment (yeah, right, whats new eh?). The customer would like to built out a set of commands on the fly (run time) and pass parameters (such as the build number, product etc.) as environment variables. Further more the customer would like to use the output of one command (e.g., success/failure etc.) as input to the next command in the sequence. It gets really fancy when the customer wants to leverage a multi-machine scenario and have VMs in the scenario be aware of each other as the bootup happens. E.g., the client waits for the server to come up first before starting the automated web test. Now, try doing all of this without guest VM automation support!

Do these above problems resonate with your scenario and what you are trying to achieve? Clearly, from the above links you will see that VMware Lab Manager has some limitations if you want to run automated processes/commands or operations within each of the guest VMs.

The VMLogix LabManager support for Guest OS automation

Among all the other rich set of functionality, VMLogix LabManager has built in support to run automated operations. As an example, you will find this VMLogix LabManager customer who has immensely benefited from the automation capability. Previously I have written about the difference between automation support for provisioning and guest OS automation — check out what exactly we mean by guest OS automation in VMLogix LabManager. Let me highlight a few of the operations in context of what customers have asked or raised above (see the 2 images below).

In the first image below, I have setup the following set of operations to run in the VM – “Machine Role 1”.

1. Install software. You can choose from a drop down list the software package to be installed. The software packages can be created and uploaded one time in the ‘software packages’ section of VMLogix LabManager.
2. Capture the newly created Virtual machine as a template. Note – that once this is done, it will be available as a standard template in the VMLogix LM library for other users. Further – this will be created as a difference disk/template, and the size will be significantly smaller than a fully created template. This helps optimize your storage utilization.
3. Take a snapshot of the image. You can setup multiple snapshots, here I have shown the first snapshot created.
4. Set an environment variable in the guest VM.
5. Run a command on the guest VM.
6. Assuming the command provides some output logs, you can upload the files to the LM server.
7. Run a user script – for example some automated test case. You might choose to have another upload command after this to upload the results of your test case. Note, LM anyway maintains the logs of commands executed which you can view at a later point.
8. Revert back the machine to the ‘clean’ state of step 3.
9. And continue executing the next set of tests (after changing the environment variable to the next build/product/…)

The above set of steps created are only an example – obviously you can choose to create a sequence that makes sense in your case/scenario choosing operations from the set in the palette. You can obviously create these set of operations for every VM that you have available in a multi-VM configuration if you so choose. You can use the “Sync” operation to keep these multi-machine setups in sync and cohesion and to setup any dependencies in the sequence of operations on each machine.

There are a lot more guest OS operations available to users, you can see the full list in the second image below. Further more, you can create custom operations – i.e., defining a new operation which will then be available via the UI to other LM users.

When I deploy the configuration below, VMLogix LabManager will deploy the VM and execute the set of operations I have specified in sequence. For a user, this is really a single click deployment and all the operations are executed automatically.

Drop me a note or leave a comment here if there is something specific that you are trying to get automated in your test lab – around creating/setting up software stacks on your test VMs. Would love to hear from you.

Sample set of operations setup to be run in sequence on a guest Virtual Machine

Set of guest OS operations available in VMLogix LabManager. You can extend this by creating custom operations as well.

[Updated] — Here is a movie of LabManager deploying a configuration with guest operations (watch the “Deploy a Multi-Machine Configuration” movie).