On 8/28/06, Warren Togami <wtogami@xxxxxxxxxx> wrote:
RH Kernel Engineer Rik van Riel recommended that we use LVM on our new
servers for flexibility in both the host and guest partitions.
If we reserve two non-LVM partitions on the primary system disk, then we
will be able to safely remote install a new OS later. We can boot
anaconda automated with kickstart or driven with VNC and reinstall
without harming the existing OS. If we fail, simply fallback thanks to
grub savedefault --once. After install, grub chainloading to the second
/boot can boot the second OS. After we confirm the new OS is working
fine, we can blow away the original host OS and reclaim the space thanks
to LVM.
The purchased Dell box has four disks.
The donated Dell box has two disks.
Here's how I envision the first two disks would be partitioned:
/dev/sda1 /dev/sdb1 => /dev/md1 /boot 200MB
/dev/sda2 /dev/sdb2 => /dev/md2 /boot2 200MB (reserved for later)
/dev/sda3 /dev/sdb3 => /dev/md3 vg0 LVM
vg0 contains:
swap 2GB
/ 10GB for host OS
All remaining space can be allocated later for Xen guests or to grow the
root partition of the host as needed.
The server with the additional two disks can software RAID-1 the entire
disk, and provide additional flexible storage as vg1 LVM. Xen guests
can go on either vg0 or vg1. We can migrate stuff as needed to balance
I/O load.
Due to instability of Xen in rawhide in the short-term, we should avoid
upgrading the host OS until it has stabilized as we approach FC6-final.
It should be relatively safe because the host OS is running only sshd
and is accessible only via bastion. Later we will be able to safely
install a host into another LVM partition to see if it runs our guests,
so risk and hassle is really minimal here.
This is just ideas from my head. If anybody here has better ideas
please suggest.
Warren Togami
wtogami@xxxxxxxxxx
WORKSFORME, I've done similar things with my Xen servers.
-Mike
