Simon,
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
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home