| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Assumption is the mother...
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home