Table of Contents

Create_DomU

Creating a Virtual Server - domU

There are 3 options of what to run DomU on:

  1. File Based Image
  2. LVM Based
  3. 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/hostname

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

umount /mnt

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

iptables -L

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 :-\

URLS at: http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-June/000563.html

http://lists.xensource.com/archives/html/xen-users/2006-04/msg00968.html