WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] PAE support revisited

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] PAE support revisited
From: Nuutti Kotivuori <naked@xxxxxx>
Date: Mon, 21 Mar 2005 21:21:32 +0200
Cache-post-path: aka.i.naked.iki.fi!unknown@xxxxxxxxxxxxxxxxxx
Cancel-lock: sha1:vinAGSmPQJh0ZztLeHHmguhso+U=
Delivery-date: Mon, 21 Mar 2005 19:23:37 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: Ye 'Ol Disorganized NNTPCache groupie
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
I will represent here a commercial look into Xen and PAE support, as
seen by my company Stinghorn (www.stinghorn.com). The points raised
are probably not too interesting from a technical standpoint.

A little background. We are currently offering virtualized products
and services on top of our own virtualization platform, which is based
on UML. However, due to the innate limitations in UML, we are
investigating Xen as an alternative.

But, the lack of PAE support, that is Xen supporting more than 4G of
memory, looks like to be an almost showstopper for us. Let me explain
why.

We need to be able to have our products working in setups of various
sizes. In the small end a setup consists of just one or few virtual
machines running on a rather low end PC, providing services. A medium
sized setup would consist of running several somewhat memory hungry
services on a single machine, such as several antivirus/antispam
gateways. And a large setup would be an operator which takes it for
granted that they will install atleast 6 gigabytes of memory into the
machine to run many virtual machines. And these are still x86 servers
we are talking about, not x86_64.

While the x86_64 support is progressing nicely, and will support more
than 4G memory, that does not really help us in this case. Even if
x86_64 support in Xen was available today, we cannot move all our
products to be x86_64 only. This is because it is still a young
platform. Companies do not have x86_64 hardware lying around for
testing. Distributions' support for x86_64 is still at times a bit
lacking - we would have to settle only for a few select Linux
distributions. There are still bugs and undiscovered problems in
running programs in 64-bit mode. And even the availability of
Intel-based x86_64 hardware is a bit of a problem. In a year, the
situation could be entirely different, but as of today, switching
everything over just is not viable.

So we would have to support x86 *and* x86_64 - x86 for all the low-end
cases and x86_64 for the cases requiring over 4G of memory. But, that
would mean that we would have to have two versions of all our products
- one for x86 and one for x86_64. Even if we would manage to have just
two different kernels and the same 32-bit userland (which is unlikely
to be without problems since some things do communicate with the
kernel), we would still have double testing effort - once for x86 and
once for x86_64. And that is a high price to pay.

We could possibly make due if Xen on x86_64 would support 32-bit
guests in a way close enough to native 32-bit so that we would only
have to test the host on x86 and x86_64 and not every different guest
we provide. But as it stands now, that doesn't seem likely.

As you can see, we are left with very little options. But if PAE
support would be in Xen, we could stay x86-only for quite some time
still. 32-bit only Xen would be fine for us until x86_64 is the norm,
instead of the exception, and there are services that really require
it.

So, we are looking into ways to make this happen. We tried to contact
XenSource, to ask if it was possible to contract the work for PAE from
them, but got no reply to our inquiries. I've seen work estimates from
two or three months to less than a month on the list - but obviously
it is hard to say without a closer look. Although personally I would
be very willing to try and make it happen, unfortunately my workload
is required elsewhere.

In any case, this is all still only under evaluation and now
commitments have been made. We do have a working platform at the
moment, even if it is not perfect, and there would have to be clear
and definite advantages within our business cases to make the
switch. But, unless this whole 4G mess gets solved somehow, it is very
likely we will reconsider Xen again in half a year or in a year, when
the world looks different again.

-- Naked



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel