Re: [Xen-users] Assumption is the mother...

[Andy Smith <andy@xxxxxxxxxxxxxx>]

On Wed, Jun 29, 2005 at 02:57:34PM +0200, John Smith wrote:
> Hi all,
> 
>       you know how to finish that line. Recently started trying xen
> (awsome!) and since the documentation is in some aspects still a bit 
> vague, I would like to get a few assumptions confirmed/denied and
> some questions answered.

I am fairly new to Xen myself but may be able to clarify a few things.

>       Domain0 is the top level kernel and manages a series of domainu
> kernels which can be of several different flavours at the moment, name-
> ly at least Linux, Free-, Open and NetBSD.

FreeBSD is still in development, I don't think an OpenBSD port
exists.  I have heard of a few people using NetBSD but don't know
how well it works.  Liux works well enough for production use.

> Windows is in the works and expected to be supported with release
> 3.0.

Windows or any other unmodified guest OS would require
VT-capable CPUs.

> All domainu kernels run as child processes of the domain0 proces.

No; the way I understand it all domains interface with the actual
Xen kernel that your boot process loads.  dom0 is special in that it
has access to the hardware and it is privileged to manage other
domains.

>       All kernels still have to be separately compiled with xen spe-
> cific options (so no really native kernels now).

Correct.

>       All kernels and their direct dependencies (/lib/modules for 
> Linux, -how about the *BSD's?-) are stored on domain0's filesystem, the 
> domains are described in domain0:/etc/xen/auto and started by 
> domain0:/etc/init.d/xendomains.

A domU's modules would need to be stored inside the filesystem of
the domU itself.

>       A kernel on disc can be shared by an unlimited number of domains.

dom0 just reads the kernel image as a normal file so yes.

>       It is recommended that each of the domains (or virtual machines)
> including domain0, have their own filesystem(s), although it may be wise
> to share read-only filesystem like /usr. 

It isn't possible to mount a normal block device more than once for
writing.  I'm not even sure if it's possible to mount it read-only
if there is another writer somewhere.

You could share filesystems with an already-existing network-aware
or clustering filesystem like NFS, GFS or OCFS.

>       Can vm's share local filesystems and if so how do they look at 
> them, NFS, local ..., and how are conflicts -filelocking etc.- handled?

You share filesystems using normal methods for sharing filesystems,
e.g. NFS, SMB, GFS, ... each of which will have their own semantics
for locking which aren't related to Xen.  It is the same issue as if
you had multiple distinct hosts on a local network and you wanted to
share filesystems between them.

>       All network communication with domain0 on a single nic machine
> (the default) is handled through a virtual bridge interface on the 
> single nic which allows access to the localhost (127.0.0.1) address of
> domain0.

A virtual interface (vif) is created and a real network device in
dom0 (e.g. eth0) is bridged to it.  Thus it behaves a bit like a
switching hub and all traffic hitting eth0 can get to the vifs it is
bridged with.  This happens below the layer where IP addresses
matter, but you would not normally see 127.0.0.0/8 addresses since
they only pass lo (loopback) and you would not bridge with lo.

Andy

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users