Table of Contents
Creating a Virtual Server - domU
There are 3 options of what to run DomU on:
- File Based Image
- LVM Based
- Physical Partition
1. A file based image is the quickest to setup, however has poor/terrible IO performance. The virtual server is limited to the initial size of the image created also. The file based Image can however be easily mounted in a rescue system, and easily backed-up.
2. LVM for domU is the industry standard. After the initial setup of LVM, as described here, it is a dream to manage. LVM partitions can be resized afterwards!!! Due to this “resizing” capability and flexibility, its use for Xen Virtual Servers is ideal. They also have much better IO performance than file-based. I dont know about mounting these partitions however in a rescue system. Something to try out… -).
3. Physical Partitions have the best IO, but are difficult to alter and inflexible.
File Based Setup of Virtual Disk
mkdir -p /xens/burkesys/ dd if=/dev/zero of=/xens/burkesys/diskimage.img bs=1024k count=5000 dd if=/dev/zero of=/xens/burkesys/swapimage.img bs=1024k count=512
mkfs.ext3 /xens/burkesys/diskimage.img mkswap /xens/burkesys/swapimage.img
mount -o loop /xens/burkesys/diskimage.img /mnt
LVM Based Setup of Virtual Disk
lvcreate -n twister –size 2g main-vol2 lvcreate -n twisterswp –size 512m main-vol2
mkfs.ext3 /dev/main-vol2/twister mkswap /dev/main-vol2/twisterswp
mount -o loop /dev/main-vol2/twister /mnt
Debootstrap New OS onto Virtual Disk
debootstrap –arch i386 sarge /mnt http://ftp.de.debian.org/debian/
mv /mnt/lib/tls /mnt/lib/tls.disabled
cp /etc/apt/sources.list /mnt/etc/apt/ vi /mnt/etc/apt/sources.list
cp -a /lib/modules/2.6.16-1-xen-k7/ /mnt/lib/modules/
cp /etc/resolve.conf /mnt/etc/
cp /etc/network/interfaces /mnt/etc/network/ vi /mnt/etc/network/interfaces
#To use Specific IP address - edit the /mnt/etc/network/interfaces manually. #To use DHCP, edit and include the following:
# The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet dhcp
vi /mnt/etc/fstab proc /proc proc defaults 0 0 /dev/sda1 / ext3 defaults,errors=remount-ro 0 1 /dev/sda2 none swap sw 0 0
Setup domU Xen Config
vi /etc/xen/burkesys kernel = “/boot/vmlinuz-2.6.16-1-xen-k7” ramdisk = “/boot/initrd.img-2.6.16-1-xen-k7” memory = 192 name = “burkesys” vif = 'bridge=xenbr0' #File Based:# disk = /xens/burkesys/swapimage.img,sda2,w' #LVM Based:# disk = 'phy:/dev/main-vol2/twister,sda2,w' #DHCP - remove the ip, gateway and netmask lines, and include:# dhcp = “dhcp” ip = “ip add” gateway = “ip add” netmask = “255.255.0.0” root = “/dev/sda1 ro” extra = '4'
ln -s /etc/xen/burkesys /etc/xen/auto/burkesys //link in the config file so that the Virtal Machine starts on Bootup of Dom0
Run and Update DomU
xm create burkesys -c // CTRL + ] Gets out of the Console
All going well you should see domU booting up. Login as “root” with no password. Execute the following commands to update: passwd pwconv #Very important. See explaination below.
apt-get update apt-get upgrade
apt-get install module-init-tools //for iptables apt-get install iptables
Fix for passwd and shadow with Debootstrap install
By default, when a system is installed using debootstrap, it does *not* create /etc/shadow, and simply creates /etc/passwd with the root password hashed. Looking at /etc/passwd after a debootstrap'ed system is running, you will see the root user and the root's password hashed. If there were other users installed on the same system, they could read the root's password hash, because /etc/passwd is world readable.
A more secure method is to store only the usernames in /etc/passwd and to store the password hash in /etc/shadow which has special permissions. Therefore any user won't be able to access the password hashes for other users. To convert passwd to shadow, its really very simple, just run: pwconv Take a look at /etc/passwd before and after, and also at /etc/shadow. Thanks to davisc for pointing out this oversight to me :)
Bug Fix for XEN3 and File Based Images
When the base machine dom0 is rebooted - the xen machines (xm create vm01 -c) wont work and will complain. A manual fix is to mount -o loop /xens/image.img /xens/mnt and then umount.
However if you add this line into /etc/init.d/xend modprobe loop max_loop=64
before echo -n “Starting $DESC: ” It will work automatically. Note - this seems to be only for file based storage