incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Update on wrapping DevCloud into a Vagrant Box
Date Thu, 12 Jul 2012 20:48:22 GMT
On Thu, Jul 12, 2012 at 4:32 PM, Chip Childers
<> wrote:
> I've been working on encapsulating the DevCloud configuration into a
> Vagrant [1] box this week.  This was something that was being
> discussed on the DevCloud thread [2], but I wanted to break it out
> into a different discussion.  I've realized that I hit a bit of a road
> block, and want to get the opinion of others in the community about
> how far I should go to get around it.
> My intent was to break up the DevCloud creation process into two
> phases.  Phase 1 could be done centrally, with the resulting image
> being updated on semi-regular basis.  It would consist of an
> unattended Ubuntu 12.04 installation (following the configuration
> guidance that Edison already provided), plus install and config
> xen/xcp/network (basically executing " -p").  Phase 1
> isn't going to be a problem really, and has nothing to do with
> Vagrant.
> My issue is in getting to the second phase, for which I was intending
> to do the code checkout, build and final configuration steps within
> the VM.
> A little bit of background on Vagrant might help those that haven't
> used it before:
> It's basically an elegant (IMO) way to encapsulate a set of
> configuration and provisioning steps for a VM (or multiple VMs) within
> VirtualBox.  It's very much designed with developers in mind.  Edison
> has already provided a fully configured OVA, but the benefit we would
> have of using something like this would be to ensure that everyone
> using the Vagrant process would be able to consistently build and
> teardown DevCloud instances with the most up to date code (or code
> from an appropriate branch).
> Vagrant has 2 functions really: VM control and "provisioning" logic.
> The former simply manages the VM's hardware configuration and state
> (registered, unregistered, running, sleeping, etc...).  The later is
> intended to provision a developer's application and config into the VM
> during a "vagrant up" call (i.e.: whenever the VM is newly started).
> To accomplish this provisioning process, there are 3 different
> "provisioner" plugins:  puppet, chef and ssh.  For these to work, the
> guest OS needs to have the VirtualBox Guest Additions installed and
> functioning...  specifically, they make heavy use of VirtualBox shared
> folders to push artifacts into the VM.  They also use ssh to interact
> with the guest OS, but it has the expectation that the shared folder
> is available to stage temporary script files for each individual
> command being sent.
> The problem that I've hit is that the VirtualBox guest additions
> kernel module is rendered non-functional when the VM is booted into
> dom0.  I'm frankly not enough of a kernel guy to figure out if there
> is a hack to make it work.  If someone else wants to give it a shot,
> I'd be more than happy to walk through the steps to reproduce the
> issue.
> As far as I can tell though, the option that I have to make Vagrant
> work is to get in contact with the maintainers of that project and
> discuss options for an alternate "provisioner" plugin (or how to use
> what's there in a different way).
> I'm looking for comments on two questions:
> 1 - Does the community (besides myself) have a significant enough
> interest in using Vagrant to make it worth the time to sort out the
> provisioner issue?

Are you installing the -headers -devel kernel packages for the Xen
kernel (I have no idea of Ubuntu/debian call the packages
-headers/-kernel - it could be that it's not not able to build the new

So the only other immediate idea is this:
Divide this up into runstages - 1 for the prep - and then when
everything is configured - change the kernel you boot too as the final
runstage, after which it should be ok that the vagrant plugin doesn't

> 2 - Does anyone have an alternate suggestion for how to achieve what I
> had hoped to achieve?

libguestfs? It certainly won't do everything, but might do some of it.

View raw message