oxenstored in stubdom ?

oxenstored in stubdom ?

[Łukasz Oleś]

Hi,

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 
(performance?). 
Is it (or will be) possible  run oxenstroed in stubdomain?

--
Łukasz Oleś

Re: oxenstored in stubdom ?

[Vincent Hanquez]

On 21/08/10 23:39, Łukasz Oleś wrote:
> Hi,
>
> 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
> (performance?).
> 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.

-- 
Vincent

Re: Re: oxenstored in stubdom ?

[Keir Fraser]

On 22/08/2010 08:34, "Vincent Hanquez" <vincent.hanquez@eu.citrix.com>
wrote:

>> So.. having xenstore in separate domain can have other advantages
>> (performance?).
>> 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.

So that's "very probably restartable" then? ;-)

 -- Keir

Re: Re: oxenstored in stubdom ?

[Vincent Hanquez]

On 22/08/10 09:23, Keir Fraser wrote:
> On 22/08/2010 08:34, "Vincent Hanquez"<vincent.hanquez@eu.citrix.com>
> wrote:
>
>>> So.. having xenstore in separate domain can have other advantages
>>> (performance?).
>>> 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.
>
> So that's "very probably restartable" then? ;-)

well yes, "very probably" is pretty good odds i think. :p

more seriously, it depends from which perspective you're looking at the 
dom0 restart problem. But according to previous experience during 
oxenstored development, i'm pretty sure that oxenstored would cope and 
that most of the problems are elsewhere in the stack. moving oxenstored 
to a stubdomain is almost orthogonal (roughly 89 degrees.)

-- 
Vincent

Re: Re: oxenstored in stubdom ?

[Keir Fraser]

On 22/08/2010 10:14, "Vincent Hanquez" <Vincent.Hanquez@eu.citrix.com>
wrote:

>>> 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.
>> 
>> So that's "very probably restartable" then? ;-)
> 
> well yes, "very probably" is pretty good odds i think. :p
> 
> more seriously, it depends from which perspective you're looking at the
> dom0 restart problem. But according to previous experience during
> oxenstored development, i'm pretty sure that oxenstored would cope and
> that most of the problems are elsewhere in the stack. moving oxenstored
> to a stubdomain is almost orthogonal (roughly 89 degrees.)

I don't think xenstored-in-stubdomain is the big barrier to dom0
restartability, that's for sure. Personally, I don't think full dom0
restartability, for things like seamless dom0 kernel upgrade, will ever be
achieved. But I think particular vulnerable or critical services within dom0
can be made restartable.

 -- keir

Re: Re: oxenstored in stubdom ?

[Łukasz Oleś]

On Sunday 22 August 2010 11:44:51 Keir Fraser wrote:
> On 22/08/2010 10:14, "Vincent Hanquez" <Vincent.Hanquez@eu.citrix.com>
> 
> wrote:
> >>> 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.
> >> 
> >> So that's "very probably restartable" then? ;-)
> > 
> > well yes, "very probably" is pretty good odds i think. :p
> > 
> > more seriously, it depends from which perspective you're looking at the
> > dom0 restart problem. But according to previous experience during
> > oxenstored development, i'm pretty sure that oxenstored would cope and
> > that most of the problems are elsewhere in the stack. moving oxenstored
> > to a stubdomain is almost orthogonal (roughly 89 degrees.)
> 
> I don't think xenstored-in-stubdomain is the big barrier to dom0
> restartability, that's for sure. Personally, I don't think full dom0
> restartability, for things like seamless dom0 kernel upgrade, will ever be
> achieved. But I think particular vulnerable or critical services within
> dom0 can be made restartable.

Thanks for clarifying.

Which are these "critical services"? Is there any list of them?

--
Łukasz Oleś

Re: Re: oxenstored in stubdom ?

[Keir Fraser]

On 22/08/2010 20:18, "Łukasz Oleś" <lukaszoles@gmail.com> wrote:

>> I don't think xenstored-in-stubdomain is the big barrier to dom0
>> restartability, that's for sure. Personally, I don't think full dom0
>> restartability, for things like seamless dom0 kernel upgrade, will ever be
>> achieved. But I think particular vulnerable or critical services within
>> dom0 can be made restartable.
> 
> Thanks for clarifying.
> 
> Which are these "critical services"? Is there any list of them?

Primarily the main toolstack (xend, xenvm, xapi, or whatever), xenstored,
xenconsoled. Xenstored is already pretty much restartable, as Vincent says.

 K.