Well, the break in between Part 1 and Part 2 was intended to be overnight. Turns out that it’s been 6 days as I battle through the struggle of trying to get my ISOs uploaded to my Ravello portal. To make a long story short, the Ravello VM Import Tool is immature, and not well suited for use on any network other than a pristine, enterprise, business-grade network. Repeated attempts from multiple locations to upload my ISO images using the tool failed miserably. I opened a support case, but they weren’t able to do anything about it. I was able to upload a file via FTP in about an hour, compared to the same file with the VM Import tool being aborted after 26 hours.
All of that being said, I did get to chat with some internal resources about this issue, and they’re aware of need for improvement in this area. They were apologetic and helpful in getting me a workaround. I would assume this issue will be resolved in short order. Also, I’m using Ravello at no charge on an extended trial, so I really can’t be too demanding 🙂
In the mean time, I created an Xubuntu VM from within Ravello and downloaded the files there, then uploaded using the CLI version of the import tool. This whole process took roughly 2-3 hours, which is perfectly acceptable.
Now that the images are finally available, it’s time to get back to building the AutoLab!
Build the DC
The first thing we need to do is connect the ISOs to the VMs. Following the deployment guide, I connected up all the ISOs to the appropriate VMs on the canvas. One interesting thing to note in comparison to the traditional AutoLab deployment is that we won’t be accessing the build share on the NAS over the network. We’re mounting the ISOs directly to the NAS and if I’m not mistaken, it has some additional automation built in to copy those files off the mounted ISOs. I also noted that the NAS platform has changes from FreeNAS to Ubuntu!
Once the VMs are configured properly, we’re ready to publish. This will actually deploy the application to either Google Compute Enginer or Amazon Web Services. In my case, I chose to go with the same configuration as the deployment guide – Amazon cloud, optimized for Performance. I set the Auto-Stop time to 6 hours because I’m not sure how long the build will take to complete. On my MacBook Pro, it usually takes about 3 hours, but just in case, I’m giving it some slack. One additional note – be sure that ‘Start all VMs automatically’ under the Advanced heading is unchecked. Just like the traditional AutoLab build, we need to start each VM in a particular order to help the build process complete. My first attempt to publish the application was unsuccessful, because in my eval account, I can’t run more than 6 VMs at once. Since my Xubuntu desktop was still powered up for circumventing the Import Tool’s issues, I had to power it down before I could publish the AutoLab application.
Once the application has been published, it’s time to power on the NAS and the DC and begin the first phase of the build. As in the traditional AutoLab deployment, the DC build takes about an hour. I’m knee-deep in a Horizon 6.1 Suite deployment at work, so I took this opportunity to read the App Volumes Deployment Guide while I monitor the build process on the DC 🙂
Once the DC build process has completed, it needs to be signed off on. We’ll run the Validate script on the desktop to be sure it’s happy and that everything is squared away for moving on to the next step – vCenter.
