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] Hi: Newbie intro.


That helps a lot.  Much of what you said matches what my impression was,
especially about Dom0.  I think in that case I will make a minimal
distro for that, and keep it simple.  At least until I decide a DomU
might not be adequate in some way, if ever.

With regards to partitioning, I think then what you're saying is that
Dom0 decides what partitions are visible to the DomU, and whether those
partitions are files on a Dom0 partition or if they're partitions on the
same "layer" so to speak.

So just guessing, I'm thinking that Dom0 would be the only thing that
needs to understand RAID/LVM and the DomUs could get by thinking it was
a plain file system.

Another thing:  I have this existing Gentoo, that I'm typing on.  Is
there some way to preserve it, or should I just figure on starting over?
Is there some way to wedge the hypervisor under it, in place?  Is that a
bad idea even if possible, or is it no big deal?

Thanks a lot, you've really helped.

-- Ken.

On Tue, 2010-08-10 at 08:02 +0100, Simon Hobson wrote:
> Ken wrote:
> >2.  Dom0 strategy:
> >I'm a bit confused as to the entire role of dom0.  Is this supposed to
> >be just a minimal command-line distro for drivers and Xen admin, or is
> >it a full-blown distro which also has Xen admin?  Do I want flexibility
> >or stability?  Rolling release or conservative non-rolling release?
> >Admin-only or do I live here?
> Dom0 is to Xen a bit like user root is to Unix style systems. Xen 
> loads first and sits on top of the hardware, but Xen itself doesn't 
> really have any way to interact with it. It loads Dom0 as the first 
> guest OS (and yes, even Dom0 is a virtual machine I believe) - and 
> gives it special privileges, such as being able to communicate with 
> the hypervisor and control it. Dom0 also gets direct access to all 
> hardware by default.
> It is customary that Dom0 is a "light" install - just containing what 
> you need to run the machine. It doesn't have to be, you can load up 
> all your GUI shells, user apps etc - but it's custom to keep Dom0 
> light because of it's privileged role and the fact that if you 
> compromise Dom0 then all the guests are compromised.
> So if you have a machine that is your desktop, then it's quite OK to 
> run Xen on it, use Dom0 as your "desktop machine" and fire up some 
> other guests as required. You just have to accept that if you 
> compromise your desktop machine, then the others are compromised too. 
> it would be a good way to get started and experiment - just not good 
> for running production services.
> >3.  Partitioning:
> >I'm currently using RAID per linux-only schemes.  Does Xen have its own
> >requirements and abilities for that, or is that entirely handled by
> >Dom0?
> >
> >Do I assign logical volumes directly to the DomUs with the proper
> >partitioning scheme or do I store everything on XFS in a big file and
> >let the DomU partition that file?
> >
> >Does it make sense still to segment the system out to different
> >partition types for performance, or what?  What's the strategy?
> Again, this is largely a matter of personal preference. In terms of 
> performance, then unless you take steps to segregate stuff (eg 
> keeping different bits of data on different drives), then the I/O 
> from all your guests shares the same disk I/O bottlenecks. In some 
> ways it could be said to be worse since you will typically have the 
> virtual disks for different machines spread across the disks and thus 
> ensure lots of head seeks.
> Xen does not handle any file systems on it's own, whatever containers 
> you use are transparent to the hypervisor. What type of container is 
> again a matter of preference.
> At one extreme, you can build a big filesystem for Dom0, and use file 
> to store the virtual disks for the guests. Personally I use block 
> devices and LVM - I create on logical volume per filesystem in each 
> DomU, and I don't partition them in the DomUs. This has the advantage 
> that each filesystem can be mounted in Dom0 without any hassles (ie 
> you can just "mount /dev/vg0/guest1root /mnt") and have access to the 
> file on the guests disks (but you must shut down the guest first).
> If you create a virtual disk and partition it inside the guest then 
> filesystems can still be mounted elsewhere, but there's an extra step 
> or two involved.
> One LV per filesystem also makes resizing filesystems a doddle - 
> shutdown guest, shrink filesystem if reducing size, resize LV, expand 
> filesystem. There is talk of it being possible to resize (expand) the 
> LV and trigger some signal to make the increased size visible to a 
> running Dom0, and then live-expand the filesystem.
> As mentioned above, many of the same performance issues arise, but 
> with some added complications because you are no longer considering 
> one "machine". If you do have a heavy I/O application, then you may 
> still want to take the usual steps of keeping that data on it's own 
> set of spindles and so on - Xen will let you do that, it really 
> doesn't care what you do.
> Dunno about the other questions.
> -- 
> Simon Hobson
> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
> author Gladys Hobson. Novels - poetry - short stories - ideal as
> Christmas stocking fillers. Some available as e-books.
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

Xen-users mailing list