Am Donnerstag, den 30.03.2006, 18:57 +0200 schrieb John Smith:
> Nils Toedtmann wrote:
> > Am Donnerstag, den 30.03.2006, 08:08 -0500 schrieb Sean Dague: 
> > > On Thu, Mar 30, 2006 at 07:43:47AM +0200, Stephan Seitz wrote:
> > 
> > [...] 
> > 
> > > > My question, is it possible to investigate this behaviour (and
> > > > ideally, xm destroy / create) from one of the live domU's ? I know,
> > > > this would be a security issue, but is there _any_ access back to the
> > > > dom0 like the xm console from dom0 to domU's ?
> > >
> > > For exactly the reasons you stated (security), the answer is no.
> > 
> > I remember reading that the only real difference between a dom0 and a
> > domU kernel is the priviledge to have access to the hypervisor. Why not
> > declaring a special domU to a "fallback" dom0? Not in the sense of
> > having access to hw but control over the hypervisor.
> > 
> > That would help if the original dom0 userland dies, but it's kernel
> > keeps forwarding/bridging packets and blockdevice-I/O, like Stephan's
> > dom0 did.
>
> if this would be a problem you would have to deal with in the
> real world, you would have a identical box on another location and move
> the domU's to it and reboot the problem box.
But that is the exact problem: afaik you cannot move domUs or reboot the
"problem box" remotely if dom0 userland is dead! You are locked. 
Even if you are running all systems redundantly (HA or cluster or
whatever) you would like to reboot the stale node remotely. So it would
be nice, if you could grant a special domU the right to reboot
everything, at least.
If you passthrough a second NIC to such a "fallback dom0" and run it
entiry from RAM w/o disk you could even recover from a locked dom0
kernel, correct?
Or use a watchdog card ...
/nils.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users