From Predictive Chemistry
Jump to: navigation, search

Virtual machines run a whole operating system, complete with kernel, but can share a physical machine, be powered on/off and transported in software. Their flexibility and ability to be customized makes them a core component of most cloud computing platforms.

Here, I document my descent into running one of these on a 32-bit Intel(R) Atom(TM) N455 running 32-bit Ubuntu 12.03. Almost all these commands must be run as root, due to unnecessarily restrictive issues with users not being able to mount filesystems in linux.

The lecture about being a smart super-user goes as follows

  1. You can permanently destroy your system as root, requiring a re-install from CD - you have been warned.
  2. check the man-pages for all commands you run as root, measure twice and cut once.
sudo /bin/bash
aptitude -P install xen-linux-system

Brctl wants to get 'in the loop' right ontop of the NIC, and multiplex from there, not by some magic decision on which incoming connections to forward to which domain. So the 'addif' won't work if you're currently connected. There are two easy options. The first (non-functional with wlan0 for me) is to let it get 'in the loop' by adding to /etc/network/interfaces:

<source lang="bash"> iface wlan0 inet manual auto xenbr0 iface xenbr0 inet manual

   pre-up iw wlan0 set 4addr on
   bridge_ports wlan0
  1. effectively runs:
  2. brctl addbr xenbr0
  3. brctl addif xenbr0 wlan0
  4. iw dev wlan0 set 4addr on


By the way, you should be able to update that without rebooting, using

service networking restart

This one didn't work for me due some problem with iwconfig getting/setting network state for the wireless radio when wlan0 had been hijacked.

The second is to use simple NAT for outgoing-initiated only network access.

Comment in /etc/xen/xend-config.sxp: <source lang="bash">

  1. (network-script network-bridge)
  2. (vif-script vif-bridge)


Add/uncomment in /etc/xen/xend-config.sxp:

(network-script network-nat)
(vif-script     vif-nat)

Uncomment (or write into) /etc/sysctl.conf <source lang="bash"> net.ipv4.ip_forward = 1

  1. net.ipv4.conf.eth0.proxy_arp = 1

</source> The second one is not required for nat, but is a gotcha for bridging, since the guest needs to respond to ARPs to get its name out there.

Make available now (this first cmd not required on reboot).

sysctl -p /etc/sysctl.conf
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

And check up on it.

iptables -t nat -S POSTROUTING

That one, for me, showed a bunch of routing rules to forward traffic over ethernet, so I used

iptables -t nat -D POSTROUTING 1

a few times. To forward, e.g., port 80 on your machine to the virtual host, use:

iptables -t nat -A PREROUTING -p tcp --dport 80 --dst $MY_IP -j DNAT --to-destination

where $MY_IP is the one listed under "inet addr:" from ifconfig wlan0.

 The Xen installers wanted to make sure you did your

homework, so you have to change the boot load order of grub to start linux_xen rather than linux first. Following along from:

mv /etc/grub.d/{20,09}_linux_xen

Yes, you really need the xen-tools for this next bit.

aptitude install xen-tools reiserfsprogs

Without the following, you would soon see cryptic package verification runes on a quest for magic rings.

apt-get install debian-keyring debian-archive-keyring

We're on a shoestring budget from an HP mini laptop, so we put our block devices on a file. There are some distro-finding errors, combined with some subtle networking errors that force on us the last few rows of options here.

<source lang="bash"> xen-create-image --hostname=lamp --memory=512mb --vcpus=2 \

 --fs=reiserfs --dir=$PWD --size=3Gb --force --keep \
 --pygrub --dist=squeeze --mirror= \
 --gateway= --ip= --netmask=


 The error log is at /var/log/xen-tools/lamp.log.  If it fails,

you probably have a few loop-devices still mounted.

losetup -a
umount /dev/loop0

Without specifying a mirror, I got:

E: Failed getting release file

The problem is that Ubuntu has its own /etc/apt-sources list, which does not jive with the base Debian distribution.

For some reason, /usr/bin/xen-create-image left that out on line 1351: <source lang="bash"> > # Default distribution is Debian Stable > $CONFIG{ 'dist' } = 'stable'; < $CONFIG{ 'mirror' } = ; > $CONFIG{ 'mirror' } = ''; </source>

To get around it, I just had to remind it of its own documentation.

The --dir option has to be a full pathname, since it's put into the /etc/xen/lamp.cfg file.

Anyway, if the image is created, write down the root password, or you'll have to

mount -o loop=/dev/loop0 domains/lamp/disk.iso /mnt

And /mnt/etc/shadow to copy a known password hash.

If all goes well, you should have a new cfg file in /etc/xen.

xm create -c /etc/xen/lamp.cfg

Now you can fuss with networking. There are some instructions here: [1] [2]

It's not clear from the walk-throughs, but dhcp won't work out of the box, since xen's dhcp management consists of trying to fix-up the ISC DHCP server's configuration (if you've already happend to set that up for 10.0.0.x). I hadn't put in all the options to xen-create-image, so I had to run (from the host)

ifconfig vif1.0 netmask
route add -net netmask vif1.0

(from the guest)

ifconfig eth0 netmask

before a ping could reach the guest, and

route add default gw

before the guest could reach the world (remember the masquerade filter was working above). You can also check that there are some rules for the new bridged-nat device by

iptables -L

-- Troubles with NetworkManager --

If, like me, you are using NetworkManager for configuring wifi, you should know that it's becoming more evil. It's started taking over bind's job (in /etc/NetworkManager/NetworkManager.conf [/etc/nm-system-settings.conf on older versions]):


leading to a loopback address in /etc/resolv.conf that destroys domU's name resolution.

Even worse, it continually cries dhclient on your shiny new vifx.y interfaces, leading to your connection breaking as it tries to install packages (mysql-server5.1 is particlarly problematic - hint: --force remove-reinstreq). The first symptom is that the ipv4 address of vif1.0 periodically disappears, leaving only a v6 addr. Like the do not call list, it also only allows 'removal' from the managed list.


(where the last xx -s are replaced by the appropriate mac, as specified in /etc/xen/lamp.cfg). I would wish it did wildcard or partial matches, but it doesn't even do multiple mac addresses, since it happily started up dhclients on a mis-mac-ed vif that I decided to semicolon append to that list. Incidentally, the vif's macs seem to change to fe:ff:ff:ff:ff:ff after awhile, even when I fixed this...

You can try to add vif's mac and restart it with: <source lang="bash"> pkill -HUP NetworkManager

  1. or service network-manager restart

</source> and kill its dhclient, found with

ps ax | grep dhcp

But the thing seems to keep ignoring its config., so I did the next-best thing, and stopped NetworkManager.

service network-manager stop
chkconfig network-manager off

and followed some advice for pre-empting nm altogether. [3] This didn't entirely work, since Ubuntu is hardwired to use NetworkManager on start-up somehow.

I also switched to wicd for wireless admin:

aptitude install wicd-gtk

It seems much less presumptuous and heavy-handed, controlling one interface, and using group-based access control. [4] [5]

-- Troubles with NetworkManager End (ideally) --

Manually changing the guest's resolv.conf will stay put, despite the doom-saying in its header, but to make the gateway changes permanent, we need the following in /etc/xen/lamp.cfg:

vif         = [ 'ip=,mac=00:16:3E:6C:BE:F3' ]

You can now complete the acronym stack via debian's package manager!

aptitude install apache2 mysql-server libapache2-mod-php5 libapache2-mod-gnutls
a2enmod gnutls

and do stupid tricks like navigating to from your host's browser.