Home > Blogs > VMware Hands-On Lab (HOL) Blog > Tag Archives: PowerCLI

Tag Archives: PowerCLI

Hands-on Labs – End of Year 2014

It has been a long time since my last post. Lest you all think we’re just sitting back and waiting for VMworld 2015, I wanted to give an update on what we have going on in the Hands-on Labs and some of the exciting work we are doing to prepare for 2015.

  1. Updated Labs: new builds, wallpaper
  2. Enhanced LabStartup
  3. FAQ
  4. Maintenance

Continue reading

Hands-on Labs: Differential Replication

blocksForgive me. It has been more than six weeks since my last post. To make up for it, this post is pretty long, weighing in at around 3,000 words. On the plus side, you only need to read all of those words in the example code output you’re really interested.

Part of the reason I have been slacking on the blog front is that our team has been working to get our new content and infrastructure built, upgraded and ready for all of you to enjoy at the VMworlds this year. We have some pretty exciting new labs in coming, as well as a some of VMworld sessions about how we run things and how some people are using our labs: INF1311 – Deploy and Destroy 85K VMs in a week: VMware Hands-on Labs Backstage and SDDC2277 – A New Way of Evaluating VMware Products and Solutions – VMwareHands-on Labs

Got Bandwidth?

There are some cases when you have plenty of bandwidth between your source and target, and other times when that is just not possible. Sill, the data must go through! So, if bandwidth between clouds is on the lower end, or if we are refreshing a version of an existing vPod, our second replication mechanism using rsync may save us quite a bit of time.

It has been said in a variety of different ways that the best I/O is the one you don’t need to do – that is especially true for moving data over great distances and/or via low-bandwidth connections. For the 2013 content year, as we developed this solution we transferred our base vPods using the LFTP method, then used the base pods as “seeds” for an rsync differential replication.

This solution is a combination of the right tools and the right process. Either one used in isolation would not provide us as much benefit as using them together. I know it sounds a bit gestalt and maybe a little cheesy, but I hope you see what I mean when you read through this post.  Continue reading

Hands-on Labs: Importing vPods

This is the fourth in my series on managing content for VMware Hands-on Labs. You can find the previous posts in the following locations:

The next phase of our multi-cloud vPod management process is sometimes a data replication, but there are times when we have multiple clouds at the same physical location. In that case, the next phase is simply an import to the target cloud. Doing this by hand is tedious and error-prone, so we employ some PowerCLI to keep us sane.

We use the built-in Import-CIVAppTemplate cmdlet for importing vApp templates. It usually does the job pretty well, but I have noticed a couple of things about the cmdlet that are worth sharing. First off, in my experience, it does not do very well with high latency links. At high latency, its bandwidth utilization is terrible when compared to even the Java-based uploader that is part of the vCD web UI. The capability to script the import process can be a worthwhile tradeoff in many cases. If the source and target clouds are geographically distributed, we usually replicate the export files to a “library” host that is LAN-connected to the target cloud and then perform the import locally anyway. I will go into more on that process in a future post in this series. Beyond that, I find that Import-CIVAppTemplate can use a little help in the resiliency department and I’ve created a little wrapper to help it out:

Continue reading

Hands-on Labs: Exporting vPods

This is the third post in my series on Hands-on Labs behind the scenes. You can find the previous post on comparing cloud catalogs here.

To date, my biggest problem with synchronizing data between vCD instances has been the time required to export vApp templates from one cloud and import them into another. If you want to preserve vApp structure and (most) metadata, there is really only one way into or out of a vCD cloud. Simply having the VMDKs and VMX file from the backend vSphere is not enough. For those who have had to deal with these mechanisms on a regular basis, you know what I mean.

A vPod containing our base infrastructure for VMworld 2013 development looked something like the following. Most of our final vPods are quite a bit larger than this, but this is a pretty standard starting point.

Single Site Base vPod
VM Name vCPU vRAM (GB) Disk (GB)
controlcenter 1 2 20
esx-01a 2 4 2
esx-02a 2 4 2
stgb-l-01a 1 2 68
vc-l-01a 2 4 33
vpodrouter 1 0.25 0.25

Continue reading

Synchronizing Cloud Catalogs

This post is part 2 in a series on the backend processes we use to manage the Hands-on Labs. The first part is available here.
Before I get into the guts of handling export, replication and import, I think it is important to understand how to identify which templates we need to work with. Sure, starting from scratch is simple: you have a bunch of templates in cloud A that you need to replicate to cloud B. Typically, that is going to take quite a bit of time. The problems involved with initial transfer to the cloud are similar to those encountered when standing up a new DR facility. Namely, how do you “seed” the DR site with the data from production. Shipping a box of tapes and performing a restore is often the least expensive option, but may not provide what you expect if your data change rate is high. That discussion is beyond the scope of this post, but I can come back around to it if there is enough interest.

“Version Control”

Back to the topic at hand. Once we have a set of clouds that host our content, we need to ensure that the templates available in each cloud are the same. As we revise our content, we check in new versions with new names. Each of our labs have a “Lab Code” or “SKU” that we use to identify them internally. For example, our wildly popular NSX lab has a SKU of “HOL-SDC-1303,” which is easier to track than the full name, “VMware NSX Network Virtualization Platform.” The first template for this lab might be called HOL-SDC-1303-v1. When we make a change to that lab, we check it in as HOL-SDC-1303-v2, then HOL-SDC-1303-v3, and so on. This is a rather simplistic practice, but it serves its purpose. Continue reading