We periodically receive requests from our users and other organizations that are interested in running their own copies of the VMware Hands-on Labs. This request frequently stems from poor network connectivity to our hosting datacenter(s), but several just want to be able to download our labs to run on their own hardware so that they don’t need to be connected to the Internet in order to go through a lab.

While we understand many of the reasons behind these requests, it is challenging for a number of reasons, not the least of which has to do with the fact that our labs are live environments. I hope to address the main issues here while providing some additional insight into what the backend of the labs looked like in 2014.

Licensing

To be honest, this is one of the bigger impediments. Licensing is directly tied to revenue, which means money, and companies tend to be a little sensitive when it comes to losing money. Since our labs are live environments that run real copies of real software products, we all need to be respectful of the license agreements and appreciate any concessions that we may receive along with their limitations. By running the labs self-contained on our own clouds, we retain control of the bits and have some measure of assurance that the licenses we use in the labs stay within the labs. We definitely cannot send pre-configured and pre-licensed versions of our products (and our partners’ products!) into the wild.

Size

Part of my responsibility on the team is moving the lab environments between sites, so I am intimately familiar with the process. When I talk about the “size” of our labs, there are several dimensions to that apply: Storage (at rest/in transit), Storage (active) and Compute are the main aspects I worry about.

Storage – At Rest/In Transit

We call our lab environments vPods. These are the miniature datacenters that we deploy to support each lab. In order to move these vPods around, they are encapsulated in an OVF (Open Virtual Machine Format). This ensures that the complete lab is stored and may be reconstituted with all of the proper settings to function properly in the target cloud or vSphere environment. This blob of data — actually, many blobs of data since the OVF process encapsulates each VMDK into a separate, compressed file — is of nontrivial size. More on that later.

Storage – Active

What does this mean to you? Say, for example, that you wanted to take one of our most popular labs, Introduction to NSX, “offline” and run it in your own environment. Assuming we remove all the other hurdles, you would need to download nearly 94 GB before unpacking that into the 465 GB that is needed to run the lab. Even with a dedicated connection between your site and mine with a usable bandwidth of 10 Mb/s, roughly 24 hours would be required to simply download the files. I’d recommend taking the hour or so to validate the SHA1 hashes here as an extra precaution. After that, the deployment would likely take at least two more hours as the files are uploaded to your local infrastructure and uncompressed. To be honest, 5+ days would be more likely given effective bandwidth all around.

Everybody likes graphs. The following shows the configured storage — the amount of storage the vPod needs provisioned in order to run — in blue, and the size of the OVF export — the amount of data that would need to be downloaded to “get” the vPod — in red.

Looking at this data a different way:

For the 2014 content cycle (VMworld 2014 – Partner Exchange 2015), our complete catalog is nearly 20 TB and the OVF exports consume slightly less than 3.5 TB.  Each OVF is between 15 and 190 GB, with an average size of around 66 GB. Incidentally, the monster is, appropriately, the “Big Data” lab: HOL-SDC-1409.

Compute

Say you do spend the 5+ days to download this big blob of lab goodness, and all of the bits came across in the proper order, and you have enough space to store and unpack it. The next challenge is being able to run it. You need a VMware vSphere 5.5 environment for virtual hardware compatibility. Think you can run this in Fusion or Workstation? Well… The NSX pod requires 17 vCPUs and 42 GB RAM. Sure, you can overcommit some of that, but those resources must run the 10 VMs and 13 nested vVMs that make up this lab, so you are not going to run this on your laptop. For what it is worth, this vPod sits pretty close to our averages with respect to required RAM and vCPUs. Ultimately, this means that you are going to need to be connected to a network to access the hosting vSphere, so the dream of running completely offline is pretty much dead.

For reference, here are the RAM and vCPU requirements for the 2014 vPods. We make every attempt to run in the smallest footprint possible for HOL, so these generally represent the minimum required for the vPods to be functional.

Network

Believe it or not, our underlying network configuration does not need to be anything terribly special. We do need the basic changes made to allow nested ESXi to run properly: Promiscuous Mode and Forged Transmits set to Accept on the vSwitch port groups that the ESXi VMs will use. Implementing the ESXi MAC Learning dvFilter fling may also help with load and performance.

Support

There is no support for the environment needed to run these labs. This question comes up regularly, and the official answer can be found in VMware KB article #2009916:

Running an ESXi host as a virtual machine is not officially supported by VMware.

This does not mean that it will not work, but is it explicitly not supported for production workloads. Beyond supporting the hosting infrastructure, there are times that we encounter an issue within a vPod and must make adjustments. When that happens, the vPod is updated, a new OVF is generated, and all copies need to be refreshed with the changes. Typically, this means any consumer would need to download the whole OVF package again and re-deploy. These constraints make supporting remote copies of the labs impractical. I am certain that our users would not be thrilled to spend a week downloading a lab only to find out that it is broken.

Conclusion

I hope that clears up some of the issues we are dealing with when considering the possibility of providing our labs as downloadable content. While we cannot provide the labs themselves, we do provide the lab manuals for all of our current labs in PDF and HTML format via our HOL Documentation portal at http://docs.hol.vmware.com/ and the labs are available for free access at http://labs.hol.vmware.com/HOL as close to 24×7 as possible. Don’t forget that the latest labs are available at VMworld, alongside the people who developed them. These teams are passionate about their labs and always willing to answer questions about them during these events. If you want to use our lab infrastructure at one of your own events, we can support that, too. Check our our HOL-in-a-box site for more information on that option.

Thanks for reading and enjoy your labs!