[clug] Virtual Machines

Tony Lewis gnutered at yahoo.com.au
Tue Sep 4 10:04:30 GMT 2007


Brett Worth wrote:
> I'm looking at aggregating some servers into a single virtualised
> host.  So far I've done some experimentation with Xen and it seems to
> work pretty well.  Rather than just forge ahead I thought I'd have a
> play with KVM but before I do I thought I'd prod the list for
> opinions.
>   

I've been bitten with the virtualisation bug for the last year or so.

My sweet spot at the moment is Xen + Linux-Vservers,  The best bit is 
that Debian etch has a kernel and userland tools that have both.  So no 
patching or compiling required.

Vservers are very lightweight - everything runs under the one kernel, 
but have isolated process spaces, file systems, and IP addresses, so for 
the most part they are blissfully unaware of each other.  A modest 
machine can run a dozen vservers without struggling.  I use these when I can

Xen has "stronger" virtualisation.  It virtualises networking more, and 
each instance runs its own kernel, so intuitively there is more 
overhead.  I hear reports it's in the order of 2-5%, so it's not 
crippling.  Thus you get things like different internal clocks.  If you 
have a VT-enabled processor, you can reportedly run non-modified guest 
OSes, namely Windows.  I haven't tried it.

The userland tools for both are nice.  The Debian Xen userland tools in 
particular are great, IMO.

Now, combine good userland tools with a local package repository, or 
apt-cacher, and you can whip up a new vserver in a couple of minutes, 
test out your idea, and then delete it again.  A couple of scripts to 
customise your template guests, and the whole process is delightfully 
pain-free.

Now for the compromises:

    * watch out for disk I/O.  If I run a "cp" command in one vserver,
      another vserver (happens to be a busy web server) crawls.
    * you can't have per-vserver firewalls, but shorewall maps well to
      managing vserver guests.  I believe per-guest packet filtering in
      Xen is OK
    * Vservers guests have no 127.0.0.1 each (it's snaffled by the host)
      so any application that tries to bind to 127.0.0.1 will fail
    * Xen won't play well with VMware, and I suspect Xen won't play well
      with OpenVZ.  Vservers play well with VMware, not sure about
      OpenVZ.  Personally, at the moment, I need VMware more than I need
      Xen, so I use a vserver-only kernel, and run VMware in a vserver guest
    * if you use Xen, you need to use a modern distro - nothing earlier
      than etch or edgy.  This is because you need a Xen-ised libc6, or
      you'll be forever deleting /lib/tls in your guests

HTH

Tony



More information about the linux mailing list