Difference between revisions of "HowTo:VirtualMachine"

From Predictive Chemistry
Jump to: navigation, search
m
m
 
Line 23: Line 23:
 
'in the loop' by adding to /etc/network/interfaces:
  
'in the loop' by adding to /etc/network/interfaces:
   
−
<syntaxhighlight lang="bash">
 +
<source lang="bash">
 
iface wlan0 inet manual
  
iface wlan0 inet manual
 
auto xenbr0
  
auto xenbr0
Line 33: Line 33:
 
# brctl addif xenbr0 wlan0
  
# brctl addif xenbr0 wlan0
 
# iw dev wlan0 set 4addr on
  
# iw dev wlan0 set 4addr on
−
</syntaxhighlight>
  
  +
</source>
   
 
By the way, you should be able to update that without rebooting, using
  
By the way, you should be able to update that without rebooting, using
Line 46: Line 46:
   
 
Comment in /etc/xen/xend-config.sxp:
  
Comment in /etc/xen/xend-config.sxp:
−
<syntaxhighlight lang="bash">
 +
<source lang="bash">
 
#(network-script network-bridge)
  
#(network-script network-bridge)
 
#(vif-script vif-bridge)
  
#(vif-script vif-bridge)
−
</syntaxhighlight>
  
  +
</source>
   
 
Add/uncomment in /etc/xen/xend-config.sxp:
  
Add/uncomment in /etc/xen/xend-config.sxp:
Line 56: Line 56:
   
 
Uncomment (or write into) /etc/sysctl.conf
  
Uncomment (or write into) /etc/sysctl.conf
−
<syntaxhighlight lang="bash">
 +
<source lang="bash">
 
net.ipv4.ip_forward = 1
  
net.ipv4.ip_forward = 1
 
#net.ipv4.conf.eth0.proxy_arp = 1
  
#net.ipv4.conf.eth0.proxy_arp = 1
−
</syntaxhighlight>
  
  +
</source>
 
The second one is not required for nat, but
  
The second one is not required for nat, but
 
is a gotcha for bridging, since the guest needs to
  
is a gotcha for bridging, since the guest needs to
Line 101: Line 101:
 
force on us the last few rows of options here.
  
force on us the last few rows of options here.
   
−
<syntaxhighlight lang="bash">
 +
<source lang="bash">
 
xen-create-image --hostname=lamp --memory=512mb --vcpus=2 \
  
xen-create-image --hostname=lamp --memory=512mb --vcpus=2 \
 
--fs=reiserfs --dir=$PWD --size=3Gb --force --keep \
  
--fs=reiserfs --dir=$PWD --size=3Gb --force --keep \
 
--pygrub --dist=squeeze --mirror=http://cdn.debian.net/debian/ \
  
--pygrub --dist=squeeze --mirror=http://cdn.debian.net/debian/ \
 
--gateway=10.0.0.1 --ip=10.0.0.10 --netmask=255.255.255.0
  
--gateway=10.0.0.1 --ip=10.0.0.10 --netmask=255.255.255.0
−
</syntaxhighlight>
  
  +
</source>
   
 
The error log is at /var/log/xen-tools/lamp.log. If it fails,
  
The error log is at /var/log/xen-tools/lamp.log. If it fails,
Line 120: Line 120:
   
 
For some reason, /usr/bin/xen-create-image left that out on line 1351:
  
For some reason, /usr/bin/xen-create-image left that out on line 1351:
−
<syntaxhighlight lang="bash">
 +
<source lang="bash">
 
> # Default distribution is Debian Stable
  
> # Default distribution is Debian Stable
 
> $CONFIG{ 'dist' } = 'stable';
  
> $CONFIG{ 'dist' } = 'stable';
 
< $CONFIG{ 'mirror' } = '';
  
< $CONFIG{ 'mirror' } = '';
 
> $CONFIG{ 'mirror' } = 'http://cdn.debian.net/debian/';
  
> $CONFIG{ 'mirror' } = 'http://cdn.debian.net/debian/';
−
</syntaxhighlight>
  
  +
</source>
   
 
To get around it, I just had to remind it of its own documentation.
  
To get around it, I just had to remind it of its own documentation.
Line 193: Line 193:
   
 
You can try to add vif's mac and restart it with:
  
You can try to add vif's mac and restart it with:
−
<syntaxhighlight lang="bash">
 +
<source lang="bash">
 
pkill -HUP NetworkManager
  
pkill -HUP NetworkManager
 
# or service network-manager restart
  
# or service network-manager restart
−
</syntaxhighlight>
  
  +
</source>
 
and kill its dhclient, found with
  
and kill its dhclient, found with
 
ps ax | grep dhcp
  
ps ax | grep dhcp

Latest revision as of 21:10, 29 April 2013

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

</source>

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)

</source>

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 10.0.0.10:80

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: http://wiki.xen.org/wiki/Xen_Beginners_Guide 

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

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=http://cdn.debian.net/debian/ \
 --gateway=10.0.0.1 --ip=10.0.0.10 --netmask=255.255.255.0

</source> 

 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 http://us.archive.ubuntu.com/ubuntu/dists/squeeze/Release

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' } = 'http://cdn.debian.net/debian/'; </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 10.0.0.1 netmask 255.255.255.0
route add -net 10.0.0.0 netmask 255.255.255.0 vif1.0

(from the guest) 

ifconfig eth0 10.0.0.10 netmask 255.255.255.0

before a ping 10.0.0.10 could reach the guest, and 

route add default gw 10.0.0.1

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]): 

dns=dnsmasq

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. 

unmanaged-devices=mac:00:16:3e:xx:xx:xx

(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=10.0.0.10,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 http://10.0.0.10/ from your host's browser.

Retrieved from "https://predictivestatmech.org/w/index.php?title=HowTo:VirtualMachine&oldid=20"