Re: [Xen-devel] questions about production use - Nick Craig-Wood - com.xensource.lists.xen-devel

10 messages in com.xensource.lists.xen-develRe: [Xen-devel] questions about produ...

From	Sent On	Attachments
Manf...@zipptec.de	23 Jan 2004 09:25
Ian Pratt	23 Jan 2004 09:37
Nick Craig-Wood	23 Jan 2004 11:45
Nick Craig-Wood	23 Jan 2004 12:01
Williamson, Mark A	23 Jan 2004 12:25
Stephen Evanchik	23 Jan 2004 17:09
Nick Craig-Wood	24 Jan 2004 00:45
Williamson, Mark A	26 Jan 2004 07:58
Nick Craig-Wood	26 Jan 2004 12:19
Williamson, Mark A	26 Jan 2004 14:41

Subject:	Re: [Xen-devel] questions about production use
From:	Nick Craig-Wood (nc...@axis.demon.co.uk)
Date:	01/23/2004 11:45:55 AM
List:	com.xensource.lists.xen-devel

On Fri, Jan 23, 2004 at 06:26:15PM +0100, Manf...@zipptec.de wrote:

After a couple of months in exploring...testing...TryToUnderstand the alternatives in the "world of virtualization" I have to decide how to build a production server.

We currently have hundreds of UMLs in production use, however we keep a close eye on other technologies. We went through exactly the same exercise as you but 2 years ago so there are more choices now (like xen!). If I were choosing today then I'd probably choose Xen - we may well swap in the future, however we've invested hugely in managing our current setup.

xen -> pros: - near to "mainframe" architecture - very high speed - high scalability with very good resource isolation - high stability (because relative low vmm complexity?) - application compatibility very high - open source

The most important one as far as I am concerned is IO scheduling. That is one thing which we do notice about UML - one UML doing heavy disk IO can really affect other UMLs. UML (and linux) is good at managing CPU, Memory, Disk space, but not IO. It is likely that 2.6 + the CBQ IO scheduler would fix this.

user-mode-linux -> cons: - a very high context switching rate

UML does impact performance you are right. However its our experience is that UMLs run out of RAM first before they run out of performance. RAM is relatively more expensive than CPU when you are trying to put 32 UMLs on a machine each with a reasonable amount of RAM, whereas a 2.4 GHz P4 is masses of power for your average server!

- relative low performance block devices (no "raw" access)

You can map uml partitions direct to block devices on the host if you want. I've never tried this though!

- resource consumption up to 80 percent and more (average ...40 ?) - no SMP for virtual servers

You can run SMP UMLs. Not sure exactly how well it works ;-)

- performance bottlenecks with high RAM servers

I'm not aware of this. Do you mean the (usual) HighMem performance problems on the host? Or are you talking about UML itself (which only goes to 512 MB at the moment I think).

[snip]

IBM mainframe Linux ... mainframe to expensive for me :-)

Yes thats the conclusion we came to ;-)

BTW You missed FreeVSD and derivatives. Also Plex86.