From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Butterworth Subject: Re: Proposal for init/kexec/hotplug format for Xen Date: Sun, 27 Feb 2005 16:05:16 +0000 Message-ID: <1109520316.4385.19.camel@localhost> References: <1109451460.32219.11.camel@localhost.localdomain> <68d3daa4e95f4ba6740c6c0ffd3f67b8@cl.cam.ac.uk> <4221E676.5000008@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit In-Reply-To: <4221E676.5000008@us.ibm.com> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Anthony Liguori Cc: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org Anthony Liguori wrote > The way I envision this working is to have a persistent store in > user-space on a priviledged domain that exported within it's tree the OF > device-tree. Keir and I briefly discussed the idea of putting the persistent store into a fault-tolerant domain to avoid it becoming a single point of failure for clustered systems. I think something along these lines is the right way to go for the long term. In the near term, if the rest of the system is architected such that fault-tolerant domains can be introduced transparently (for example by ensuring, amongst other things, that the API exposed to driver authors for the FE-BE inter-domain communication interface is compatible with an alternative network transparent implementation so you don't have to rewrite all the drivers ;-) then the domain running the persistent store can be upgraded with fault-tolerance in the future. -- Harry Butterworth ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click