WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [RFH] xen domain0 failover stuff

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [RFH] xen domain0 failover stuff
From: Don Zickus <dzickus@xxxxxxxxxx>
Date: Mon, 27 Mar 2006 17:08:42 -0500
Delivery-date: Mon, 27 Mar 2006 22:07:22 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
Hello,

I am ignorantly trying to find a way to start a second domain0 when the
first domain0 crashes.  My original intent was to find a way to collect a
core file much in the same way the domainU core files are collected on a
linux box.  

I managed to hack in some hooks to get a second domain0 loaded and started
upon a crash.  However, I am stuck without console output, ie printk() is
not working.  Oddly, early_printk() works fine and I can sort of track the
progress of the second domain0 as it boots.  So my first question is how
does the serial console (not vga) magic work for a domain0 kernel?  Do I
have to set some internal domain bits to have the console output
redirected to the serial port as opposed to userspace and xend (ala
domainU kernels)?  

I attached my small dirty hack below, if it helps. The jist of it is I
added a new parameter, "failover", to be read in from a domainU config
file (ie /etc/xen/guest).  The second domain0 is treated just like a
domainU kernel in regards to loading and installing the userspace disk.
The only thing different is "xm create -c guest" will load a domain0
kernel instead of a domainU kernel.  Combined with the "failover" flag
above, this triggers the hypervisor to reserve this domain as a backup for
later and _not_ unpause the domain once its cpu context is loaded.  Upon
the first domain0 crash, the hypervisor looks up the backup domain0,
mindlessly sets some interesting bits, and unpauses it.  

Pretty simple.  

Any help or tips or pointers would be great.

Cheers,
Don

 

Attachment: xend.patch
Description: Text document

Attachment: xen.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel