The Xen team would like to start submitting upstream the patches
required to enable Linux to run over the Xen 2.0 Virtual Machine
Monitor. For more information about Xen see: http://xen.sf.net
There are three main classes of patch required:
core : small patches that provide extra hooks for arch-xen
arch-xen : large patch to add arch/xen and include/asm-xen
xen-drivers : patch to add virtual block, network and console drivers
We're proposing to submit the 'core' patches first, as these
probably require closest inspection (the others are all new
files in new directories, so can't break existing architectures).
There is already a significant user base and lively developer
community backing the Xen project, so we're confident we will
have the resources to maintain arch-xen on Linux 2.6 going
forward (as well as Linux 2.4/NetBSD/FreeBSD/etc).
Let us know what you think of the patches ;-)
Cheers,
Ian, Keir, Christian, Steve
Original Xen 2.0 release annoucement:
The Xen team are pleased to announce the release of Xen 2.0, the
open-source Virtual Machine Monitor. Xen enables you to run
multiple operating systems images concurrently on the same
hardware, securely partitioning the resources of the machine
between them. Xen uses a technique called 'para-virtualization'
to achieve very low performance overhead -- typically just a few
percent relative to native. This new release provides kernel
support for Linux 2.4.27/2.6.9, NetBSD and FreeBSD.
Xen 2.0 runs on almost the entire set of modern x86 hardware
supported by Linux, and is easy to 'drop-in' to an existing Linux
installation. The new release has a lot more flexibility in how
guest OS virtual I/O devices are configured. For example, you can
configure arbitrary firewalling, bridging and routing of guest
virtual network interfaces, and use copy-on-write LVM volumes or
loopback files for storing guest OS disk images. Another new
feature is 'live migration', which allows running OS images to be
moved between nodes in a cluster without having to stop
them. Visit http://xen.sf.net for downloads and documentation.
Ian Pratt <[email protected]> writes:
> arch-xen : large patch to add arch/xen and include/asm-xen
This is 32bit only right? Do you plan a 64bit guest too?
If yes, you would end up with two arch-xens in the end.
Also are the differences to the native architecture really that big that a
separate architecture makes sense? It's a lot of long term work to maintain
a Linux architecture.
-Andi
Hi,
On Wed, 17 Nov 2004 23:43:53 +0000, Ian Pratt <[email protected]> wrote:
> Let us know what you think of the patches ;-)
So where are they? Please post them to LKML so others don't have to go
digging around for them.
Pekka
On Thu, 18 Nov 2004 08:59:07 +0200, Pekka Enberg <[email protected]> wrote:
> Hi,
>
> On Wed, 17 Nov 2004 23:43:53 +0000, Ian Pratt <[email protected]> wrote:
> > Let us know what you think of the patches ;-)
>
> So where are they? Please post them to LKML so others don't have to go
> digging around for them.
Aah, sorry about that, found them already. Please consider posting the
patches as a reply to the original mail next time. They're easier to
grab that way.
Pekka
> Ian Pratt <[email protected]> writes:
>
> > arch-xen : large patch to add arch/xen and include/asm-xen
>
> This is 32bit only right? Do you plan a 64bit guest too?
> If yes, you would end up with two arch-xens in the end.
We have an x86_64 guest port in progress, hence the current
directory structure below arch/xen. There's a fair bit of
arch/xen-specific code that we can share between the ports.
> Also are the differences to the native architecture really that big that a
> separate architecture makes sense? It's a lot of long term work to maintain
> a Linux architecture.
We've experimented with doing thing the other way round, having
xen a sub architecture of i386, but it was _really_ messy.
I firmly believe that having a separate arch/xen is the best
approach for the moment. In the future, it might make sense to
merge arch xen into i386, but to do this cleanly would require
significant restructuring of i386. I think that's something we
could move toward after everyone's gotten comfortable with having
arch xen in the tree.
The fact that arch xen is self contained actually makes it easier
for us to maintain in some respects. We've been tracking 2.6
releases for some time without too much difficulty.
Best,
Ian
On Thu, Nov 18, 2004 at 10:23:50AM +0000, Ian Pratt wrote:
> The fact that arch xen is self contained actually makes it easier
> for us to maintain in some respects. We've been tracking 2.6
> releases for some time without too much difficulty.
2.6 has been relatively easy for now (because it was supposed
to be a "stable kernel"), but I suspect it'll get worse again over time.
e.g. in 2.5 it was really bad for long times.
Essentially you will need to commit significant man power to this.
Also it's quite hard to always catch all the changes that
get done to i386.
Overall I think it's a bad idea to have four different
x86 like architectures in the tree. Especially since there
will be likely more hypervisors over time. i386 and x86-64 make
some sense because 64bit is a natural boundary, but extending
it elsewhere doesn't scale very well.
-Andi
Andi> Overall I think it's a bad idea to have four different x86
Andi> like architectures in the tree. Especially since there will
Andi> be likely more hypervisors over time. i386 and x86-64 make
Andi> some sense because 64bit is a natural boundary, but
Andi> extending it elsewhere doesn't scale very well.
Is there any possibility of Xen someday being ported to some non-x86
architecture (eg ppc64 or ia64)?
- Roland
> Andi> Overall I think it's a bad idea to have four different x86
> Andi> like architectures in the tree. Especially since there will
> Andi> be likely more hypervisors over time. i386 and x86-64 make
> Andi> some sense because 64bit is a natural boundary, but
> Andi> extending it elsewhere doesn't scale very well.
>
> Is there any possibility of Xen someday being ported to some non-x86
> architecture (eg ppc64 or ia64)?
Non x86 architectures are generally much easier to virtualise, so
its possible to do it within the existing architecture port.
As a case in point, the soon-to-be-released IA64 port of Linux
just requires just a few patches to the standard architecture. I
expect PPC will be fairly similar.
x86 and x86_64 are a real pain, hence the separate architecture
approach.
Over time, I hope we can merge the i386 xen port in with the
native architecture, but its going to require significant
restructuring of the native architecture to do it cleanly. In
the meantime, I think we just have to bite the bullet and
maintain a separate architecture. I believe we have resources to
do this.
Ian
Ian Pratt wrote:
> Original Xen 2.0 release annoucement:
>
> The Xen team are pleased to announce the release of Xen 2.0, the
> open-source Virtual Machine Monitor. Xen enables you to run
> multiple operating systems images concurrently on the same
> hardware, securely partitioning the resources of the machine
> between them. Xen uses a technique called 'para-virtualization'
> to achieve very low performance overhead -- typically just a few
I wasn't about to mention this, but since you reposted it I will. I
shared the original post with a number of people and at least three
mentioned it.
The term "low performance overhead" just seems to make people thinks
it's slow, and they don't read past it. I highly suggest either "low
overhead" or "low performance impact" would avoid this.
Perhaps I just know a lot of other people who suffer from literalism.
> percent relative to native. This new release provides kernel
> support for Linux 2.4.27/2.6.9, NetBSD and FreeBSD.
>
> Xen 2.0 runs on almost the entire set of modern x86 hardware
> supported by Linux, and is easy to 'drop-in' to an existing Linux
> installation. The new release has a lot more flexibility in how
> guest OS virtual I/O devices are configured. For example, you can
> configure arbitrary firewalling, bridging and routing of guest
> virtual network interfaces, and use copy-on-write LVM volumes or
> loopback files for storing guest OS disk images. Another new
> feature is 'live migration', which allows running OS images to be
> moved between nodes in a cluster without having to stop
> them. Visit http://xen.sf.net for downloads and documentation.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me