Thank you. Documenting it would be good for now. sent fr0m a $martphone, excuse typ0s On Jan 19, 2012 2:28 PM, "Mike McClurg" <mike.mccl...@gmail.com> wrote:
> On Thu, Jan 19, 2012 at 7:47 AM, Ritesh Raj Sarraf <r...@debian.org> wrote: > > On Wed, Jan 18, 2012 at 3:00 AM, Thomas Goirand <z...@debian.org> wrote: > >> On 01/17/2012 02:47 PM, Ritesh Raj Sarraf wrote: > >>> But the problem is, xcp-xapi wants to have xend disabled. > >>> > >>> [ ... ] > >>> > >>> So I disabled the xend init file and then ran into this problem. > >> > >> No wonder why then! Nobody ever wrote/said that you should do that. The > >> xend init.d script does a lot more than just starting xend. It also: > >> - modprobe the xenfs and xen-evtchn kernel modules > >> - mounts /proc/xen as xenfs > >> - Starts xenconsoled > >> - Starts xenstored > >> > >> If the above isn't done, then there's no way that XCP, or even Xen, will > >> ever work! The only thing that should be disabled is starting xend, all > >> the rest should stay. > >> > > > > What do you mean by "disable starting xend" ? > > > > We'd like that the xend init script continue to start the other > services that xpi-xapi relies on, but only actually start the xend > daemon iff TOOLSTACK=xm. This way we don't have to worry about > renaming or splitting init scripts. > > > For now, just calling the xend stop in the xapi init script should fix > > the problem. > > > > Agreed, but as was pointed out to me by Ian Campbell, that's a bit of > a hack, since one service shouldn't be allowed to just shut another > one down. I was in favour of making this change to xcp-xapi.init > temporarily, until the xend init script is modified to only > selectively start xend, but I think now that we should instead ask > users to work around this issue until we sort out the xend script. The > simplest work-around is to ask the user to add the line 'service xend > stop' to the user's xcp-xapi.init script. > > Thomas, I believe that you submitted a patch to xend.init to check > TOOLSTACK=xm. Do you know the status of this patch? > > Mike >