<html lang="en">
<head>
<title>Libvirt - BuildBot Manual - 0.8.4p1</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="BuildBot Manual - 0.8.4p1">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="up" href="Latent-Buildslaves.html#Latent-Buildslaves" title="Latent Buildslaves">
<link rel="prev" href="Amazon-Web-Services-Elastic-Compute-Cloud-_0028_0022AWS-EC2_0022_0029.html#Amazon-Web-Services-Elastic-Compute-Cloud-_0028_0022AWS-EC2_0022_0029" title="Amazon Web Services Elastic Compute Cloud ("AWS EC2")">
<link rel="next" href="Dangers-with-Latent-Buildslaves.html#Dangers-with-Latent-Buildslaves" title="Dangers with Latent Buildslaves">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
This is the BuildBot manual for Buildbot version 0.8.4p1.
Copyright (C) 2005, 2006, 2009, 2010 Brian Warner
Copying and distribution of this file, with or without
modification, are permitted in any medium without royalty
provided the copyright notice and this notice are preserved.-->
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
pre.display { font-family:inherit }
pre.format { font-family:inherit }
pre.smalldisplay { font-family:inherit; font-size:smaller }
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
span.sc { font-variant:small-caps }
span.roman { font-family:serif; font-weight:normal; }
span.sansserif { font-family:sans-serif; font-weight:normal; }
--></style>
</head>
<body>
<div class="node">
<a name="Libvirt"></a>
<p>
Next: <a rel="next" accesskey="n" href="Dangers-with-Latent-Buildslaves.html#Dangers-with-Latent-Buildslaves">Dangers with Latent Buildslaves</a>,
Previous: <a rel="previous" accesskey="p" href="Amazon-Web-Services-Elastic-Compute-Cloud-_0028_0022AWS-EC2_0022_0029.html#Amazon-Web-Services-Elastic-Compute-Cloud-_0028_0022AWS-EC2_0022_0029">Amazon Web Services Elastic Compute Cloud ("AWS EC2")</a>,
Up: <a rel="up" accesskey="u" href="Latent-Buildslaves.html#Latent-Buildslaves">Latent Buildslaves</a>
<hr>
</div>
<h5 class="subsubsection">4.9.3.2 Libvirt</h5>
<p><a href="http://www.libvirt.org/">libvirt</a> is a virtualization API for interacting
with the virtualization capabilities of recent versions of Linux and other OSes.
It is LGPL and comes with a stable C API, and python bindings.
<p>This means we now have an API which when tied to buildbot allows us to have slaves
that run under Xen, QEMU, KVM, LXC, OpenVZ, User Mode Linux, VirtualBox and VMWare.
<p>The libvirt code in Buildbot was developed against libvirt 0.7.5 on Ubuntu Lucid. It
is used with KVM to test python code on Karmic VM's, but obviously isn't limited to that.
Each build is run on a new VM, images are temporary and thrown away after each build.
<h3 class="heading">Setting up libvirt</h3>
<p>We won't show you how to set up libvirt as it is quite different on each platform,
but there are a few things you should keep in mind.
<ul>
<li>If you are running on Ubuntu, your master should run Lucid. Libvirt and apparmor are
buggy on Karmic.
<li>If you are using the system libvirt, your buildbot master user will need to be in the
libvirtd group.
<li>If you are using KVM, your buildbot master user will need to be in the KVM group.
<li>You need to think carefully about your virtual network *first*. Will NAT be enough?
What IP will my VM's need to connect to for connecting to the master?
</ul>
<h3 class="heading">Configuring your base image</h3>
<p>You need to create a base image for your builds that has everything needed to build
your software. You need to configure the base image with a buildbot slave that is configured
to connect to the master on boot.
<p>Because this image may need updating a lot, we strongly suggest scripting its creation.
<p>If you want to have multiple slaves using the same base image it can be annoying to duplicate
the image just to change the buildbot credentials. One option is to use libvirt's DHCP
server to allocate an identity to the slave: DHCP sets a hostname, and the slave takes its
identity from that.
<p>Doing all this is really beyond the scope of the manual, but there is a
vmbuilder script and a network.xml file to create such a DHCP server in
<code>contrib/</code> (see <a href="Contrib-Scripts.html#Contrib-Scripts">Contrib Scripts</a>) that should get you started:
<pre class="example"> sudo apt-get install ubuntu-vm-builder
sudo contrib/libvirt/vmbuilder
</pre>
<p>Should create an ubuntu/ folder with a suitable image in it.
<pre class="example"> virsh net-define contrib/libvirt/network.xml
virsh net-start buildbot-network
</pre>
<p>Should set up a KVM compatible libvirt network for your buildbot VM's to run on.
<h3 class="heading">Configuring your Master</h3>
<p>If you want to add a simple on demand VM to your setup, you only need the following. We
set the username to minion1, the password to sekrit. The base image is called base_image
and a copy of it will be made for the duration of the VM's life. That copy will be thrown
away every time a build is complete.
<pre class="example"> from buildbot.libvirtbuildslave import LibVirtBuildSlave
c['slaves'] = [LibVirtBuildSlave('minion1', 'sekrit',
'/home/buildbot/images/minion1', '/home/buildbot/images/base_image')]
</pre>
<p>You can use virt-manager to define 'minion1' with the correct hardware. If you don't, buildbot
won't be able to find a VM to start.
<p><code>LibVirtBuildSlave</code> accepts the following arguments:
<dl>
<dt><code>name</code><dd>Both a buildbot username and the name of the virtual machine
<br><dt><code>password</code><dd>A password for the buildbot to login to the master with
<br><dt><code>hd_image</code><dd>The path to a libvirt disk image, normally in qcow2 format when using KVM.
<br><dt><code>base_image</code><dd>If given a base image, buildbot will clone it every time it starts a VM.
This means you always have a clean environment to do your build in.
<br><dt><code>xml</code><dd>If a VM isn't predefined in virt-manager, then you can instead provide XML
like that used with <code>virsh define</code>. The VM will be created
automatically when needed, and destroyed when not needed any longer.
</dl>
</body></html>
