WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Search Results for: vmc

Ravello: An interesting solution using Nested Virtualization

08.08.2013 by William Lam // 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.

Categories // Uncategorized Tags // binary translation, hypervisor, nested, nested virtualization, ravello, startup

Nested Virtualization Resources

10.04.2012 by William Lam // 7 Comments

Here is a consolidated page on all the articles that I have written about the Nested Virtualizatoin (nested ESXi, Hyper-V, etc) and all the goodies that are "Not Supported".

vSphere / vCloud 5.1

  • Having Difficulties Enabling Nested ESXi in vSphere 5.1?
  • How to Enable Nested ESXi & Other Hypervisors in vSphere 5.1
  • How to Enable Nested ESXi & Other Hypervisors in vCloud Director 5.1

vSphere / vCloud 5.0

  • How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5
  • The Missing Piece In Creating Your Own Ghetto vSEL Cloud

Additional Info/Tips/Tricks/

  • Nested ESXi 5.1 Supports VMXNET3 Network Adapter Type
  • How to Configure Nested ESXi 5 to Support EVC Clusters
  • How to Enable Nested vFT (virtual Fault Tolerance) in vSphere 5
  • How to Install VMware VSA in Nested ESXi 5 Host Using the GUI
  • Cool Undocumented Features in vCloud Director 1.5
  • The Missing Piece In Creating Your Own Ghetto vSEL Cloud
  • Nested Virtualization APIs For vSphere & vCloud Director 5.1
  • How To Enable Nested ESXi Using VXLAN In vSphere & vCloud Director 
  • Will Intel’s VMCS Shadowing Feature Benefit VMware’s Nested Virtualization?
  • How to run Nested RHEV Hypervisor on ESXi? 
  • How to quickly setup and test VMware VSAN (Virtual SAN) using Nested ESXi
  • How to run Nested ESXi on top of a VSAN datastore? 
  • VMware Tools for Nested ESXi 
  • Why is Promiscuous Mode & Forged Transmits required for Nested ESXi?
  • How to properly clone a Nested ESXi VM?

Categories // Uncategorized Tags // amd-v, ept, ESX 4.0, ESXi, ESXi 4.1, ESXi 5.0, ESXi 5.1, hyper-v, intel vt, nested, rvi, vhv, virtual hardware virtualization, vSphere, vSphere 4.0, vSphere 5.0, vSphere 5.1

Scripts to Extract vCloud Director Chain Length and Linked Clone Mappings

04.09.2012 by William Lam // 18 Comments

There were some questions this week about extracting the chain length for a virtual machine as well as figuring out which Linked Clones were mapped to a particular vAppTemplate and/or shadowVM in vCloud Director. If you are not familiar with the concept of a Linked Clone (Fast Provisioning in vCloud Director 1.5 leverages Linked Clones) and their relationship to chain length, there is a very good white paper called VMware vCloud Director 1.5 Performance and Best Practices that goes into detail about Linked Clones and some of the things to be aware of from a performance standpoint.

Depending on how you deploy a new vApp whether that is from a vAppTemplate in your catalog or copying from an existing vApp, the chain length of a Linked Clone tree will grow either breadth wise or length wise.
The chain length can grow much faster when copying from an existing vApp and that can impact the performance of your virtual machines. Below is a diagram between deploying from a vAppTemplate in a catalog (breadth wise) and consecutive copies from an existing vApp (length wise).

vCloud Director limits the chain length to 30 and automatically spins up a full clone (called a shadow VM) when the maximum is hit and all sub-sequent Linked Clones will be based off of this new shadow VM. A shadow VM can also spin up automatically if the current datastore is getting to full capacity or if the VM needs to exists on a different vCenter Server as Linked Clones do not span datastores or different vCenter Servers.

To view the current chain length of a given virtual machine, you will need to login with a System Administrator account and this can be seen using the vCloud UI at the VM level. You can also get the chain length using the vCloud API which is part of the VCloudExtension property called VirtualDisksMaxChainLength and can be viewed by performing a GET operation on a VM.

Note: Though the property has "MaxChainLength" in the name, this property represents the current chain length and it is not configurable, as the system max is 30.

To be able to quickly get a summary of the chain length of all VMs that include vAppTemplates and Shadow VMs, I wrote a vCloud SDK for PHP script called vcloudVMChainLength.php. The script provides a few pieces of information: VM name as shown in vCloud Director, name of the vApp the VM is part of in vCloud Director, whether it is a vAppTemplate, the vCenter Server hosting the VM, the MoRef of the VM and chain length.

Before I provide the sample output, let me give you some background about my lab environment. I have two vAppTemplates called "Application Server" and "Database Server". The "Application Server" is currently residing on a datastore with close to full capacity and I will be deploying 3 new vApps from this vAppTemplate called "App-Test-1", "App-Test-2" and "App-Test-3". I will also be deploying 3 new vApps from "Database Server" but only the first clone will be from the vAppTemplate, the remainder will be a clone of the previous vApp in the workspace.

Here is a diagram of the 9 VMs (2 vAppTemplates, 1 shadow VM and 6 vApps):

Here is the sample output of the environment above:

We can see that during the deployment of the "App-Test-*" vApps, the datastore capacity was low and vCloud Director automatically spun up a shadow VM which is a full copy and created the 3 new Linked Clones off of that image and the chain length is max of 2. With the "DB-Test-*", we started out with deploying from the vAppTemplate, but all subsequent copies was from the previous vApp which grew the chain length to 4. If we continue to copy from the vApp length wise, we will quickly reach the maximum chain length and possibly degrade the performance of the VMs as the deepest node will need to traverse back to the parent to perform it's disk read operations. 

The other question I had was about mapping the Linked Clones back to their parent VMs. This is not something you can really do in vCloud Director nor using the vCloud API. However, with a little bit of creativity and information from vCloud Director, you can leverage the vSphere API to help you get a list of VMs that are linked off of a given VM. I wrote a vSphere SDK for Perl script called vCloudVMLinkedClonesMapping.pl that can help you get this information. 

Note: This was tested in my lab which had a minimal configuration, ensure you do additional validation before making any decisions based on the output.

To use the script, you will need to provide the MoRef ID for a VM that is either a vAppTemplate, shadow VM or just a regular VM which may have Linked Clones. You can get this information by using the script that was shown earlier.

Let's take a look at our "Application-Server" VM which has MoRef ID 677 and see if there are any Linked Clones:

As we expected, there are no Linked Clones as the datastore it is currently residing on is getting to full capacity and a shadow VM was spun up for the new 3 deployments.

Let's take a look at the shadow VM "shadow-App-VM" with MoRef ID 721 which is automatically prefix with "shadow-" of the source VM name:

Just as we expected, we can see that our 3 vApps are linked off of the Shadow VM that we just checked.

Note: The output includes the display name and URN ID of the vApp in vCloud Director so you can easily identify it.

Finally, let's take a look at our "Database-Server" VM which has MoRef ID 675 and we should also see the 3 Linked Clones:

You might ask if it is necessary to keep track of all this information and the answer is yes/no. Though it is good to understand how vApps are being deployed by your consumers and ensure they are efficiently doing so by deploying from a catalog. vCloud Director has built in mechanisms to automatically handle deep chain lengths or low datastore space by deploying additional shadow VMs to ensure users are still able to request new vApps without any impact.

Categories // Uncategorized Tags // chain, linked clones, php, vcd, vcloud director

  • « Previous Page
  • 1
  • …
  • 51
  • 52
  • 53
  • 54
  • 55
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Configuring OIDC with PKCE in Keycloak for VCF Private AI Services 08/26/2026
  • VCF 9.1 - Understanding VCF Converge & Import Scenarios for vCenter Server Without NSX 08/24/2026
  • VCF 9.1 - Configuring Harbor to use VCF Identity Broker (IDB) for External Identity Federation 08/19/2026
  • Quick Tip: The Fastest Way to Clear Partitions for ESX Reinstallation 08/15/2026
  • Quick Tip: Reducing High CPU Utilization in VCF Automation (VCFA) on AMD Zen4/Zen5 CPUs 08/12/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026