Local testing with KVM, VDE and dnsmasq: Difference between revisions

From FAIWiki
Jump to navigation Jump to search
m (typo)
(Add warning.)
Line 1: Line 1:
'' Note: this howto is not yet complete, or at least has not been confirmed to be working''
== Motivation ==
== Motivation ==


Imagine you already have a production infrastructure using FAI. You keep your config space in revision control and the production servers only have read-only access to the repository. Of course, you don't want to clog up the changelog with lots of revisions while testing changes. And of course, if you deploy a not perfectly tested change on your production infrastructure, and a colleague installs a server just at that moment, bad things can happen.
Imagine you already have a production infrastructure using FAI. You keep your config space in revision control and the production servers only have read-only access to the repository. Of course, you don't want to clog up the changelog with lots of revisions while testing changes. And of course, if you deploy a change that has not been fully tested on your production infrastructure and a colleague installs a server just at that moment, bad things could well happen.


Or maybe you just can't be bothered to test everything on real servers. After all, they can be pretty slow to boot up with hardware RAID controllers, remote access cards and the like all needing to be initialized.
Or maybe you just can't be bothered to test everything on real servers. After all, they can be pretty slow to boot up with hardware RAID controllers, remote access cards and the like all needing to be initialized.
Line 30: Line 32:
Bring up the interface with <tt>ifup tap0</tt>. Also, we are going to want to run the virtual machine as a normal user later on. Add your user to the <tt>vde2-net</tt> group to make this possible.
Bring up the interface with <tt>ifup tap0</tt>. Also, we are going to want to run the virtual machine as a normal user later on. Add your user to the <tt>vde2-net</tt> group to make this possible.


== Internet access ==
If your installation system requires access to the internet, for instance because it accesses a network mirror (you can of course install apt-proxy on your workstation instead), you will want to do something like the following:
If your installation system requires access to the internet, for instance because it accesses a network mirror (you can of course install apt-proxy on your workstation instead), you will want to do something like the following:
<pre># sysctl -w net.ipv4.ip_forward=1
<pre># sysctl -w net.ipv4.ip_forward=1
Line 35: Line 38:
(where <tt>eth0</tt> is the interface via which you are connected to the internet.)
(where <tt>eth0</tt> is the interface via which you are connected to the internet.)


== Setting up dnsmasq ==
=== Setting up dnsmasq ===


(This section will be written soon.)
(This section will be written soon.)

Revision as of 17:52, 13 October 2009

Note: this howto is not yet complete, or at least has not been confirmed to be working

Motivation

Imagine you already have a production infrastructure using FAI. You keep your config space in revision control and the production servers only have read-only access to the repository. Of course, you don't want to clog up the changelog with lots of revisions while testing changes. And of course, if you deploy a change that has not been fully tested on your production infrastructure and a colleague installs a server just at that moment, bad things could well happen.

Or maybe you just can't be bothered to test everything on real servers. After all, they can be pretty slow to boot up with hardware RAID controllers, remote access cards and the like all needing to be initialized.

Or maybe you want to be able to work on your FAI configuration on your laptop while on the train, with no ready access to your regular DHCP and TFTP infrastructure.

In such cases, you would like to be able to work on your FAI configuration without leaving the comfort of your own workstation. And since even laptops are equipped with insane amounts of RAM nowadays, virtualization is an obvious solution.

Goal

This Howto is written for Debian Lenny. It will show you how to install a KVM virtual machine via PXE, connected to your workstation via VDE, with dnsmasq providing DHCP and TFTP services.

Please note that KVM is not a very good option if you have an old CPU with no virtualization extensions. Check your /proc/cpuinfo for the vmx or svm flag.

Setting up Virtual Ethernet

For this Howto, we are going to use to use the network 172.25.25.0/24. Of course, you can use any other network you like, adjustments should be fairly obvious.

First of all, install the Debian package vde2.

Add the following stanza to /etc/network/interfaces:

iface tap0 inet static
  address 172.25.25.1
  netmask 255.255.255.0
  vde2-switch -

Bring up the interface with ifup tap0. Also, we are going to want to run the virtual machine as a normal user later on. Add your user to the vde2-net group to make this possible.

Internet access

If your installation system requires access to the internet, for instance because it accesses a network mirror (you can of course install apt-proxy on your workstation instead), you will want to do something like the following:

# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

(where eth0 is the interface via which you are connected to the internet.)

Setting up dnsmasq

(This section will be written soon.)

Setting up FAI

Install fai-server. Note that you don't need dhcp3-server and tftpd-hpa which are pulled in by default. Configure as usual by editing files in /etc/fai. Furthermore, put the following in /etc/fai/make-fai-nfsroot.conf:

SERVERINTERFACE="tap0"

Run fai-setup and fai-chboot -IBv default to generate the NFS-Root and the PXE configuration.

Setting up and running KVM

(This section will be written soon.)

For the impatient:

kvm-img create -f qcow2 faitest.img 5G
vdeq kvm -m 256 -net nic,vlan=1 -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl -hda faitest.img -boot n