On Sun, 2008-06-29 at 12:20 +0800, tgh wrote:
> hi
> I am interested in this issue, and I wonder wether we could manage
> dom0 in xen architecture, that is ,to boot dom0, to reboot it ,to store
> it ,or restore it ,while suspending domU in memory ,through some domctl
> whenever necessary, or could we develop some new hypercall to make it
> work ,or does xen architecture have some inherent limit in itself and
> have no compatibility with this potential augment? and why not or
> how to achieve it , could some one give some advise on it
Dom0 maintains a lot of information reflecting overall system state,
including that of other guest systems. There's e.g. xenstore, typically
most, if not all of the backend machinery used to serve guests. There's
the qemu device emulation. All of these are stateful interfaces exposed
to guests.
So you'd have to save/restore all that (volatile) information to rehost
other guests seamlessly after a reset. Not like it's absolutely
undoable, but it'd be tricky and still easy to break during upgrades.
Then there's dom0 as the maintenance interface at the foreground of your
console machine interface. If that reboot fails, you're left with a
completely nonoperational system, since the VMM provides no (or only
minimal) interaction itself.
It's a neat idea, but unlikely to be practical unless you move critical
parts of its duties into different VMs, and at that point maybe even not
so interesting anymore.
Best,
Daniel
--
Daniel Stodden
LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München D-85748 Garching
http://www.lrr.in.tum.de/~stodden mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home