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 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). 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 kernel on disc can be shared by an unlimited number of domains. 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. Can vm''s share local filesystems and if so how do they look at them, NFS, local ..., and how are conflicts -filelocking etc.- handled? 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. 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
> 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 andDon''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 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users