WilliamLam.com

Quick Tip - Automate the export of a vCenter Orchestrator workflow using the CLI

by // 5 Comments

Steve Jin recently wrote an article about vCenter Orchestrator REST APIs: Executing Workflow which reminded me of an interesting issue that I had faced several months back. I had just finished developing a custom workflow on a beta version of vCenter Orchestrator and of course one of the challenges with using early software is that it could be unstable. I was unable login to the vCO interface via vSphere Web Client or the vCO Client to export my workflow through the regular UI interface. I tried everything and I thought I might have lost my workflow!

I reached out to one of the vCO engineers and asked if there was an easy way to recover my workflow and it turns out there was a very simple method IF the vCO REST API endpoint is still accessible, which it was. To test this, you can either use cURL on the command-line or your favorite REST Client for your browser and perform a GET operation on the following URL (replace the URL with the URL of your vCO Server):

https://vco.primp-industries.com:8281/api/workflows

Note: The vCO REST API is only available starting with vSphere 5.1

If the command was successful, you should see a list of all the workflows in your vCO Server:

I am not aware of any filtering that can be done to narrow down the specific vCO Workflow, but if you are using a browser-based REST Client, you can just search for the name of your workflow. In the above example, I am interested in the "Change Guest OS Type" workflow and you can see its corresponding vCO Workflow ID which is highlighted.

To export and save the vCO Workflow to your local system, you just need to perform a GET operation on the vCO Workflow URL and specify "Accept:application/zip" for the request header which will allow you to save the vCO workflow.

Here is an example using cURL to export the  vCO Workflow and save to a file called ChangeGuestOS.workflow:

curl -i -k -u vcoadmin -H "Accept:application/zip" -X GET https://vco.primp-industries.com:8281/api/workflows/7D808080808080808080808080808080BC818080013141141566711a974a8fef8 -o ChangeGuestOS.workflow

Ravello: An interesting solution using Nested Virtualization

by // 6 Comments

As many of you know, I am a huge fan of VMware Nested Virtualization and I am always interested to learn how customers and partners are using this technology to help enable them to solve interesting problems. I recently met up with a startup company called Ravello who has a product that leverages Nested Virtualization in a very unique way.

Note: Ravello is not the only company using Nested Virtualization in interesting ways. Bromium, another startup in the security space, is also doing interesting things with Nested Virtualization.

Ravello is a SaaS solution that allows you to take an existing VMware or KVM virtual machine and without any modifications to that VM, run it on a variety of public cloud infrastructures including Amazon EC2, HP Cloud, Rackspace and even private clouds that are running on vCloud Director (support coming soon). Ravello is basically "normalizing" the VM by virtualizing it in their Cloud Application Hypervisor so that it can run on any cloud infrastructure.  From the diagram below, the unmodified VM is actually running inside of another VM which runs a flavor of Linux. This Linux VM loads up their HVX Hypervisor and is running on one of the public cloud infrastructures.

Similar to a regular hypervisor, HVX provides an abstraction, but instead of the underlying physical hardware it abstracts away the underlying cloud infrastructure. The HVX hypervisor provides the following three core capabilities:

  • Presents a set of virtual hardware that is compatible with VMware ESXi, KVM and XEN virtual machines
  • Virtual networking layer that is a secure L2 overlay on top of the cloud infrastructure L3 networking using a protocol similar to GRE but running over UDP
  • Cloud storage abstraction that provides storage to the VM through Ravello Image Store that can be back-ended by Amazon S3, CloudFiles or even block/NFS volumes

My first thought after hearing how Ravello works, is that this is pretty neat! Of course the next logical question that I am sure most of you are asking is how is the performance? We know that running one level of Nested Virtualization will incur some performance penalty and this will continue with additional levels of Nested Virtualization. Ravello is also not leveraging Hardware-Assisted Virtualization but Binary Translation (a technique developed by VMware) as that can not be guaranteed to be available on all cloud infrastructures. In addition to Binary Translation, they are also using various techniques such as caching and chaining translated code, fast shadow MMU, direct execution of user space code and few others to efficiently run in a nested environment.

I was told that performance was still pretty good and sometimes even out performing regular cloud infrastructures. There was no mention of specific applications or performance numbers, so I guess this is something customers will need to validate in their own environment. I am also interested to see what the overhead is by doing two-levels of Nested Virtualization and what impact that has to the guestOS and more importantly, the applications. To be fair, Ravello's current target audience is Dev/Test workloads, so performance may not be the most critical factor. They also provide two modes of deployment based on cost optimized or performance and if the latter is selected, overcommitment of resources or consolidation will not be used.

Overall, I thought Ravello's solution was pretty interesting and could benefit some customers looking to run their workloads in other public cloud infrastructures. I think performance is just one of the things customers will need to consider but also how do they go about managing and operating this new VM container and how tightly integrated is Ravello with the VMware platform or other hypervisors for that matter. Though the VM and the underlying applications does not need to change, what operational challenges does this introduce to administrators? 

Ravello also recently presented their HVX Cloud Application Hypervisor at a recent USENIX conference and you can find more details in their presentation called HVX Virtualizing Cloud along with their research paper which can be found here.

One thing that I did want to point out after watching the presentation is that one of the presenter mentioned that their HVX nested hypervisor runs more efficiently than any other hypervisor out there and that others would require things like Intel's VMSC Shadowing feature to be comparable. I can not speak for other hypervisors, but when running VMware Hypervisors on top of our ESXi Hypervisor, our hypervisor has already been optimized for VMREAD/VMEXITS and Intel's VMSC Shadowing feature would only benefit slightly. You can read more about those techniques in this blog article.

Ravello will be at VMworld US booth #425 and I will probably drop by for a demo to see their solution in action.

Do I need to install both the vSphere CLI & vSphere SDK for Perl?

by // 1 Comment

I received this question from one of our TAMs (Technical Account Managers) last week asking what is the difference between the vSphere CLI and the vSphere SDK for Perl and whether you need to install both of them. The simple answer is there is no difference, but why do we have two packages then? Well, this was probably due to how the vSphere SDK for Perl and the vCLI was initially introduced and was distributed in two separate packages.

Starting with the vSphere SDK for Perl 4.0, both the SDK packages and the vCLI commands have been combined together. However, it looks like both packages are still being produced as part of the automated build process and this will be consolidated in a single distribution in a future release. Going forward, you can just download the vSphere CLI which is always tied to a vSphere release and you will be ensured that is fully compatible with the latest release.

For more details behind each of the packages, you can take a look at the quick summary below:

vSphere SDK for Perl

The vSphere SDK for Perl is just a client-side Perl framework that provides administrators with a scripting interface to the vSphere API. As part of the SDK (Software Development Kit) it also provides a variety of sample scripts.

vSphere CLI

The vSphere CLI or the vCLI for short is just a set of command-line scripts that implements a sub-set of the functionality from the vSphere API. These scripts include the vicfg-* commands which are remote version of the legacy esxcfg-* commands, as well as ESXCLI, vmkfstools and resxtop commands that can also be run remotely. Most importantly, the vicfg-* commands are built on top of the vSphere SDK for Perl and this is one of the reasons you need to have the vSphere SDK for Perl installed if you wish to use the vCLI commands.