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/
Home Products Support Community News


Re: [Xen-users] Portability (was Re: Users can provide...)

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Portability (was Re: Users can provide...)
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Wed, 15 Jun 2005 19:26:13 +0100
Cc: Sascha Retzki <sretzki@xxxxxx>
Delivery-date: Wed, 15 Jun 2005 18:25:22 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050615151705.GG3471@MEniac>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <36967cc905061503081361da34@xxxxxxxxxxxxxx> <200506151536.16998.mark.williamson@xxxxxxxxxxxx> <20050615151705.GG3471@MEniac>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.7.1
> > By "weird filesystems" I really meant that this bootloader approach will
> > support any guest filesystem that Linux can support.  This includes the
> "Linux": No.. the library of the program you mentioned, pyGrub. Right?

The PyGrub approach runs the bootloader in dom0 using filesystem libraries.  
The kexec-based approach runs the bootloader in the domU you are starting, as 
an application.

> > Adding support to the dom0-based loader shouldn't be *that* hard but does
> > require explicit use of a new filesystem library.  Also, I doubt that all
> > FSes supported by Linux have such a library available...
> Isn't that just bloat? What is actually "hard" to just boot the first
> sector of the filesystem, wihtout knowing nothing about it at all?

The hard bit is writing a bootloader that'll do that: you can't run real Grub 
in a guest because it expects to run on bare x86 hardware.  This means we'd 
need to write a Xen-aware port of Grub (or your favourite bootloader) *and* 
that port would have to include support for each filesystem you might use.

The most straightforward approach is to run the bootloader app in dom0 and use 
existing filesystem libraries to access the guest filesystem (as is currently 
done).  The "second most" straightforward approach is to boot Linux in the 
guest, then have that load the "real" guest kernel and execute it.

> > I don't know much about Linux's UFS support.  However, if it's able to
> > mount UFS read-only that'd be enough.  Can it do this reliably?
> Well "reliably" ;) .. I mounted UFSs RO in the past, But I rather mount
> ext2 from any BSD ;)

As long as we can grab a kernel out of it that's good enough.  It'd be nice if 
Linux supported UFS better than it does - I'm surprised the support isn't 
more advanced, actually.

> > > Speaking of it, as there are several Operating Systems out there which
> > > want to act as a domO-able OS, too - How "portable" do you think Xen
> > > is?
> >
> > Xen itself shouldn't need to be modified at all for this - guests need to
> > be ported to use the dom0 and privileged interfaces, which are OS
> > independent...
> Eh, sorry I misused terminology. I meant the user-space tools needed
> by the dom0 to control the other domains, so the "frontend" (I like that
> term :) ).

Sure, just meant that you can already run lots of things as a guest.  
"frontend" is the driver used by the guest.  "backend" is the driver that 
provides virtual devices.  "privileged interface" support is needed to run 
the whole machine.  To run as a guest, you just need frontend drivers.

Anyhow, we're a long way from running Xend in a Windows dom0 but I don't think 
there's that much of the code that's UNIX specific.


Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>