>>> Ewan Mellor <ewan@xxxxxxxxxxxxx> 07.12.06 16:53 >>>
>On Thu, Dec 07, 2006 at 03:21:59PM +0000, Jan Beulich wrote:
>
>> As any other daemon, I'd assume it should be possible to restart xenstored
>> (i.e.
>> if it crashed or if, during development, a fix was made to it that needs to
>> be
>> tested). However, as I learned after over a day of digging, things don't work
>> anymore after doing so: Since the watches are transient, they're lost with
>> the
>> daemon going away.
>> Right now I specifically need this in already mentioned scenarios where I
>> want
>> to not touch the base installation of a system or need parallel versions
>> installed,
>> but as described above I see the general issue broader (e.g. it obviously
>> doesn't make sense to try to start xenstored from 'xend restart' because of
>> described problems).
>
>xend restart doesn't restart xenstored, for this very reason of course.
It does, in case it isn't already running (i.e. if it crashed).
>I don't see why this is a problem for your "multiple installed versions of
>Xen" -- surely you reboot in order to switch toolstacks?
I obviously need to reboot, as the tools need to match the hypervisor.
>Keir did have some ideas about making xenstored restartable -- reregistering
>the watches when the daemon restarts -- but no-one's got around to doing that
>work. Are you volunteering? ;-)
No, I'm not. There's more than enough other stuff I'd like to deal with. And
I'm neither very familiar with the tools subtree, nor am I keen on touching it.
>> For some reason, this wasn't a big problem when the base installation was
>> 3.0.2-based - apparently something else prevented xenbus' event channel
>> handler to get triggered when the 3.0.2 xenstored loaded, and hence all the
>> needed watches got installed only when the proper version was loaded the
>> first time, giving the impression that things work as expected (until perhaps
>> reloading it a second time).
>
>You've lost me -- what are you trying to do? Are you trying to start multiple
>versions of xenstored during the same boot?
Yes - as the system's base configuration (obviously, as long as the xen package
is installed) tries to start xend. xend itself fails (due to mismatching change
sets),
but blktapctrl, xenstored, and xenconsoled all load successfully.
>Xenstored actually hasn't changed in any manner that would make it
>backwards-incompatible, AFAIK, so you ought to be able to run a 3.0.2
>toolstack with xenstored from 3.0.4, for example.
Obviously not - otherwise I wouldn't have this difference in behavior between
a system with 3.0.2 installed where I try to run 3.0.3 or -unstable (which
succeed the first time through) and one with 3.0.3 installed where I try to run
-unstable (and things don't work).
As pointed out before - apparently the notification to the kernel's xenbus
piece doesn't get through from 3.0.2 xenstored to a post-3.0.2
kernel/hypervisor, resulting in the watches not getting registered until an
appropriate xenstored loads. Using -unstable with a 3.0.3 xenstored, on
the other hand, results in xenbus_probe() getting invoked right away.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home