July 28, 2015 by jdg Leave a Comment

AutoLab 2.6 on Ravello – Build the vCenter & Hosts (Part 3)

Part 3 of this series has been a long time coming. I’d been running into some serious problems getting vCenter to build properly, and then I ran out of hours on my promotional hours allotment from the kind folks at Ravello. So I had to wait until I got some fresh hours. To the right, you can see the sorts of problems I was having. My hosts would frequently PSOD either while building, or while booting. I’m really not sure what’s going on, and I’ve been pressed for time, so I didn’t open a case with Ravello to have them check it out. My feeling is that it’s probably just kinks that need worked out from what amounts to what’s been lovingly referred to as hypervisor Inception. (via HVX)

My advice after having sorted through this, which is also in the AutoLab 2.6 Deployment Guide, is to just keep trying. Eventually, I did get it to work as intended, and I didn’t do anything different. It just worked one time. So, after a long wait, here’s a few notes on the steps required to get the hosts and vCenter built.

Build the Hosts

The hosts and vCenter can be built at the same time. The deployment guide says to start them at the same time. Because the hosts are required for the vCenter build to finish (assuming you’ll run the AddHosts script as a part of the build) I opted to get the hosts started before getting the vCenter build started. There’s a trick, and I can’t remember where I heard this – select all three hosts and start them at once as opposed to starting them one at a time. The reason for this is that starting them in one command will launch them on the same back-end hypervisor, causing performance of communication between the three hosts to be improved. Again, I can’t remember where I got that tip, and I can’t find it in the deployment guide, so correct me if I’m wrong 🙂

Assuming the DC build completed successfully, it’s running a PXE server that the hosts will boot an install wizard from. From the menu, on each host, select ‘ESXi [version] automated builds’ and then the corresponding build (e.g. Host1 Automated Install). This will build the respective host with the correct settings like hostname, IP address, and so on.

Once you’ve selected a host to build and the process completes, you’ll be left with a fully configured ESXi host. All that’s left is to get them connected to an added vCenter server. Powering on the vCenter server will get the build started, and it generally takes around an hour to complete. An option was set during the DC build to add the hosts to vCenter during the build, so first the OS customization script will run and set up the box, install vCenter, and dependencies/utilities (utilities being things like 7-zip, PuTTy, etc). Once the OS is ready, vCenter is installed, and the script gets PowerCLI installed, it will kick off the script that customizes vCenter. This builds out everything like the datacenter, cluster, adds hosts, adds datastores, and more.

Once the vCenter script is totally finished (it might be best not to watch it like I did – feels like an eternity!) the final action will be to install VMware Tools and reboot, just like the DC did. Once the reboot is complete and the OS is automatically logged in again, open the AutoLab Script Menu from the shortcut on the desktop and validate the build just as was done on the DC.

And there you have it! Assuming the vCenter is built, you can log in to vCenter via the vSphere Client using credentials in the ‘as-built’ documentation. You will find a fully configured environment with as many hosts as you chose to build. In my build for this post, I just had it build 2.

July 27, 2015 by jdg 1 Comment

Vagrant Series » Project Setup, Vagrantfiles, and Boxes (Part 3)

In the previous post in this series, I looked at how to provision an Ubuntu box with Vagrant in a matter of moments. Now that the process is understood and the power of Vagrant has been seen, it’s time to break it down a little bit and show how Vagrant is able to create a fully functioning VM with a simple vagrant up.

Vagrant Project Setup

When deploying a new development environment, the first thing to do is set up an area for all of the project files. In the previous post, vagrant init hashicorp/precise32actually created the project in whatever directory the terminal was open to. For a bit more organization moving forward, I prefer to create a folder for a given Vagrant environment. The configuration files will be stored here, as will any supporting files. For instance, a www share for an Apache server might exist in this folder. Creating a new project is easy.

mkdir VirtAdmin
cd VirtAdmin/
vagrant init

In the desired location, just create a new folder, and from within that folder run vagrant init.This will automatically generate a Vagrantfile! What’s a Vagrantfile, you might ask?

[Read more…]

July 10, 2015 by jdg 1 Comment

Vagrant Series » Synced Folders (Part 4)

Developing with local tools (IDE, Sublime/Coda/etc) but testing code on a remote machine or local VM can be painful because of the effort required to push the updates to the machine running the application. Vagrant solves this problem with the concept of Synced Folders. For me, this is easy to relate to VMware’s Shared Folders feature of Fusion/Workstation. And as it turns out, this is exactly what’s happening – the Shared Folders feature of the provider is what enables this functionality. This feature allows a local folder to be mirrored with a folder in the guest OS of a virtual machine. What this accomplishes is that very little effort is required to make updates using local tools, but have the changes reflected in the development environment.

Setting up Vagrant Synced Folders

Synced folders are actually enabled by default; the project directory (the one your Vagrantfile lives in) will be shared with the guest OS at /vagrant. That’s handy enough for getting files back and forth. But the real power of this feature can be shown with a simple example. Let’s say the running Vagrant machine is an Apache server. By sharing the DocumentRoot folder with the host OS, development can be done on the same files that are serving the web page. This means no pushing and pulling to see the changes you’ve made reflected live. Setting up Synced Folders for a given objective is simple: just add the config.vm.synced_foldermethod to the project’s Vagrantfile, specifying the path on the host machine and then the path on the guest machine.

As an example, on my machine I’m using a Vagrant box to do WordPress development for this site. I’m able to play with CSS and make changes to the site’s appearance without tinkering with the live version. Testing new plugins offline is also something I do with this. In the Vagrantfile for my testing box, the following configuration shares the website files:

config.vm.synced_folder "www/", "/srv/www/", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

The extra options at the end set permissions on the directory, and specify options to pass to the mount command. This allows me to use Sublime Text 3 and other tools on my MacBook Pro to manipulate the files actively being served from the web server I have spun up. In a more complex environment, you may want to enable/disable the Synced Folder based on conditionals during project setup. Disabling the share can be accomplished by appending disabled: trueto the line.

Alternatives

Depending on the environment, a Shared Folders feature for the provider may not be available. But not to fear! A Synced Folder configuration can also be set up to use NFS for Linux machines (or RSync when nfsd is not available on either the host or guest) and SMB for Windows machines. This means that with few exceptions, Synced Folders can be configured in every environment.

See the full official documentation on Synced Folders here, and don’t forget that the project root is already synced to /vagrant! Next up, a brief look at Vagrant networking.