Installation of multiple Linux Instances

[Chris Snook]

kevin kempter wrote:
> Thanks for the info..
> 
> one question - I need top performance since I'm dealing with very large 
> databases. any suggestions per virtualization?  I've tried vmware 
> workstation with unacceptable performance results...

You need paravirtualization, which means Xen or KVM+virtio.  Since virtio isn't 
available in many of the guest OSes you'll be using, you're left with Xen.  You 
probably want to run RHEL/CentOS 5.2 in your dom0.  RHEL 4.5 and later can run 
paravirtualized under Xen, as can any remotely recent Fedora.  Debian has also 
recently added Xen support.

Also, make sure you're using logical volume-backed virtual disks, not file-backed.

-- Chris

> On Sep 19, 2008, at 3:27 PM, Chris Snook wrote:
> 
>> kevin kempter wrote:
>>> Hi List;
>>> I have a new dev server. As an independent consultant I want to 
>>> maximize it's use. Some of my clients use RedHat/CentOS 64 bit, 
>>> others Redhat/CentOS 32bit, some are even using Fedora and Debian.
>>> Here's my thought:
>>> I'd like to install each OS/version into it's own space on the disk.  
>>> I'm thinking all I have to do is install one OS (say CentOS 64bit) 
>>> and partition say 20% of the disk. Then once the install is done, 
>>> boot into the latest fedora disk and do the same, etc.
>>> Is this correct ?
>>> Later I want to add a disk array and allocate a RAID mount point that 
>>> can be mounted by any of the installed Linux'es when it's active.
>>> Is this do-able ? Easily ?
>>> Thanks in advance...
>>
>> If you can virtualize, you should, because it's a lot simpler, but if 
>> you can't, this is what I routinely do to solve this problem:
>>
>> 1)    Start with a grub-based distro first for ease of bootloader 
>> configuration. Make sure it's one you have a rescue disk for in case 
>> you screw something up and need to reinstall grub.
>>
>> 2)    Allocate a small /boot partition (200MB should be plenty) and 
>> put almost all of the rest of the disk in an LVM volume group, but 
>> leave a few GB free.
>>
>> 3)    Allocate your swap space and other shared filesystems (such as 
>> /home) in the LVM volume group.  All modern (2.6 kernel) distros will 
>> be able to use these. Allocate your root filesystem out of this volume 
>> group as well.  10 GB should be more than enough for any distro's root 
>> filesystem.
>>
>> 4)    When you install additional distros, allocate a small /boot 
>> partition out of the free space you left when partitioning, and put 
>> the rest in LVM.  Make sure to install the bootloader for the 
>> additional distros to the first sector of their boot partition, rather 
>> than the MBR, so it doesn't blow away the primary grub installation.  
>> This is usually an option under "advanced bootloader options" or 
>> something like that.  If you accidentally blow away the grub 
>> installation, you should be able to reinstall grub with the rescue 
>> disk for the primary distro.
>>
>> 5)    Create a chainload entry in the grub.conf for the primary 
>> distro, pointing to the /boot partition for the new distro, like this:
>>
>> title chainload RHEL5 (sda3)
>>     rootnoverify (hd0,2)
>>     chainloader +1
>>
>> Now, at boot time, you'll get the list of kernels installed on the 
>> primary distro, and list of the other distros you can chainload.  If 
>> you choose one of the other distros, it will launch that distro's 
>> bootloader, and then boot it normally.
>>
>> This is a little bit of a pain, but it works.  I recommend using 
>> virtualization when suitable, as it saves a lot of the hassle of 
>> bootloader configuration. Putting most of your disk in LVM will also 
>> allow you to allocate logical volumes to be virtual disks, which is 
>> MUCH faster than file-backed virtual disks, so this partitioning 
>> scheme works for both purposes.
>>
>> Make sense?
>>
>> -- Chris
>>
>> -- 
>> fedora-list mailing list
>> fedora-list at redhat.com
>> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>> Guidelines: 
>> http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
>