Mailing List Archive

> 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.

Not OpenBSD - I'm not aware of any porting effort in the OpenBSD community.

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

Running Windows will require additional hardware support - i.e. a CPU upgrade
to a new virtualisation-enhanced processor. Unmodified Linux / BSD guests
run now but it might take a bit longer (i.e. post 3.0) to support Windows
(extra 16 bit cruft to support == extra work).

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

Not exactly. All domains on Xen are basically "equal". The only difference
with a domU is that it's not allowed to access the hardware. They uses
shared memory and Xen "event channels" to proxy IO through dom0.

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

Yup. Without hardware assist, you need to modify a guest to run on Xen. The
benefit is improved performance over binary-compatible (full) virtualisation.

> All kernels and their direct dependencies (/lib/modules for
> Linux, -how about the *BSD's?-) are stored on domain0's filesystem,

The modules go in the guest filesystem. The kernel only needs to be in dom0's
FS so it can build the guest's initial memory image before kicking it into
life

nb in 3.0 you can store guest kernels on the guest FS and choose between them
using (soon to be a choice of two!) bootloaders.

> the
> domains are described in domain0:/etc/xen/auto and started by
> domain0:/etc/init.d/xendomains.

Yup. Or you can start them manually using "xm create" if yuo don't
use /etc/xen/auto.

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

Yup. Independent copies get made in each domain's initial memory image.

> 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.

Sharing as anything but read-only will break things. Multiple writers will
fry your filesystem.

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

Use NFS or some other network protocol. You'll be able to use XenFS for this,
which will be faster. It's not ready fr use yet (partly because I've been
having too much fun with kexec).

> 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.

Other domain's network adapters are connected with "virtual crossover" to
dom0. It can do what it wants with them - the default is to create a
(standard) Linux bridge and bridge them onto the network. You can do
anything (bridging, routing, tunnelling, etc) you want, though.

Cheers,
Mark

>
> Thanks for commenting on my idiocy and for xen.
>
> Sincerely,
>
> Jan.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

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

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.
>
> 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. Windows is in the works and

Don't know about OpenBSD, I assume they don't want it. NetBSD works
even as dom0, but xentools are a bit linux-centric so its a bit harder
to achieve goals, imho. FreeBSD xen support is on the way.

> expected to be supported with release 3.0. All domainu kernels run as
> child processes of the domain0 proces.
>
> All kernels still have to be separately compiled with xen spe-
> cific options (so no really native kernels now).
>

Right. Xen3 is said to change that, tho.

> 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.
>

That is not a must. To be particular, I think it is even to depreciate.
You can make a file, a LVM, a NFS-exported fs or a real partition
visible to unprev. domains as harddisks (imho).

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

I don't see a "why not"-reason, but never did that.

> 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.
>

Yes - two considerations from on top of my head:

- security: If the security of one domain is broken, the security of all
other domains is, too.

- well a bit stupid, but NetBSD cannot share the userspace with FreeBSD
and so on ;-)

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

A, good one, add that to the above list ;-)

>
> 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.
>

I think so, yes. Did not get that far yet ;)

Networking in Xen seems a bit strange (to me?), so I'd like to comment
and explain on that a bit further, hoping that more advanced users
may correct me here:

Domain0 sees all the real hardware and assigns it drivers to the NICs.
Basing on the configuration (nics = directive), DomainUs may see 0-N
NICs, but in a virtual way. The network traffic can then be NATed by
Domain0 so that DomainUs can communicate with other 'puters on the
network.

So you have a PF in between them, and can control which NICs a domU
actually "sees".

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

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