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


[Xen-devel] Re: oxenstored in stubdom ?

To: Łukasz Oleś <lukaszoles@xxxxxxxxx>
Subject: [Xen-devel] Re: oxenstored in stubdom ?
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Sun, 22 Aug 2010 08:34:08 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 22 Aug 2010 00:34:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201008220039.11900.lukaszoles@xxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <201008220039.11900.lukaszoles@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100805 Icedove/3.0.6
On 21/08/10 23:39, Łukasz Oleś wrote:

recently on irc channel (##xen) was some "discussion" about xen vs kvm...

There was idea that it would be nice if domUs could survive dom0 restart, but
this needs, for example, to have xenstored running in separate domain.

In 2009 Alex Zeffertt posted some patches
(http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00696.html) to
add this functionallity, but they weren't applied.

So.. having xenstore in separate domain can have other advantages
Is it (or will be) possible  run oxenstroed in stubdomain?

oxenstored is already restartable (or used to be and easy to fix if it was broken), so from a xenstore point of view, you could already restart dom0; Obviously this would block all the domains that try to do a xenstore query, but if the dom0 is restarted quickly enough this shouldn't be too noticeable since a normal working domain shouldn't use much xenstore after starting up.

Regarding performance nobody profiled oxenstored in this context as far as i know; I'm not sure that would be a win, and i would much rather squeeze performance in the code directly than move xenstored in a complicated setup.


Xen-devel mailing list