Difference between revisions of "HowTo:VirtualMachine"
(Created page with "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 abilit…") |
m |
||
Line 204: | Line 204: | ||
service network-manager stop |
service network-manager stop |
||
chkconfig network-manager off |
chkconfig network-manager off |
||
− | and followed some |
+ | and followed some advice for pre-empting nm altogether. [http://www.sevenforge.com/2009/07/28/connecting-to-wpa-wifi-on-the-command-line/] |
+ | This didn't entirely work, since Ubuntu is hardwired to use NetworkManager on start-up somehow. |
||
I also switched to wicd for wireless admin: |
I also switched to wicd for wireless admin: |
Revision as of 17:43, 27 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
- You can permanently destroy your system as root, requiring a re-install from CD - you have been warned.
- 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:
<syntaxhighlight lang="bash"> iface wlan0 inet manual auto xenbr0 iface xenbr0 inet manual
pre-up iw wlan0 set 4addr on bridge_ports wlan0
- effectively runs:
- brctl addbr xenbr0
- brctl addif xenbr0 wlan0
- iw dev wlan0 set 4addr on
</syntaxhighlight>
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: <syntaxhighlight lang="bash">
- (network-script network-bridge)
- (vif-script vif-bridge)
</syntaxhighlight>
Add/uncomment in /etc/xen/xend-config.sxp:
(network-script network-nat) (vif-script vif-nat)
Uncomment (or write into) /etc/sysctl.conf <syntaxhighlight lang="bash"> net.ipv4.ip_forward = 1
- net.ipv4.conf.eth0.proxy_arp = 1
</syntaxhighlight> 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.
<syntaxhighlight 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
</syntaxhighlight>
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: <syntaxhighlight lang="bash"> > # Default distribution is Debian Stable > $CONFIG{ 'dist' } = 'stable'; < $CONFIG{ 'mirror' } = ; > $CONFIG{ 'mirror' } = 'http://cdn.debian.net/debian/'; </syntaxhighlight>
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: <syntaxhighlight lang="bash"> pkill -HUP NetworkManager
- or service network-manager restart
</syntaxhighlight> 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.