Hi, Is there some easy way to install both 2.x and unstable xen tools at the same machine? Seems /usr is hardcoded everythere in the tools Makefiles, looks like there is no easy way to put them to different paths (say, prefix /opt/xen2 and /opt/xen3) :-/ Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Is there some easy way to install both 2.x and unstable xen > tools at the same machine? Seems /usr is hardcoded everythere > in the tools Makefiles, looks like there is no easy way to put > them to different paths (say, prefix /opt/xen2 and /opt/xen3) > :-/No easy way that I know of - we typically just use different root file systems here to ensure that everything is completely separated. cheers, S. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 30 May 2005, at 14:22, Gerd Knorr wrote:> Is there some easy way to install both 2.x and unstable xen > tools at the same machine? Seems /usr is hardcoded everythere > in the tools Makefiles, looks like there is no easy way to put > them to different paths (say, prefix /opt/xen2 and /opt/xen3) > :-/Have you tried a ''make dist'' and then e.g., ''cp -a dist/install /opt/xen2'', then add appropriate paths to the front of PATH, LD_LIBRARY_PATH, PYTHONPATH? ''DESTDIR=/opt/xen2 make install'' also ought to work in a similar way. Neither of the above is well-tested, but we would expect them to work. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Is there some easy way to install both 2.x and unstable xen > > tools at the same machine? Seems /usr is hardcoded everythere > > in the tools Makefiles, looks like there is no easy way to put > > them to different paths (say, prefix /opt/xen2 and /opt/xen3) > > :-/ > > No easy way that I know of - we typically just use different root > file systems here to ensure that everything is completely separated.Hmm, thats exactly what I want to avoid ... I suspect the unstable tools can''t be used to manage 2.x machines? Gerd -- -mm seems unusually stable at present. -- akpm about 2.6.12-rc3-mm3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Have you tried a ''make dist'' and then e.g., ''cp -a dist/install > /opt/xen2'', then add appropriate paths to the front of PATH, > LD_LIBRARY_PATH, PYTHONPATH?Works sort of. I have the 2.x versions in /usr now (normal suse 9.3 rpms), 3.x in /opt/xen3/usr. xend complains that it can''t start xcs and doesn''t come up. When I start xcs manually first it works. I''d guess xend tries to start the 2.x version in /usr/sbin although /opt/xen3/usr/sbin comes first in $PATH ... Gerd -- -mm seems unusually stable at present. -- akpm about 2.6.12-rc3-mm3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/31/05, Gerd Knorr <kraxel@suse.de> wrote:> > Have you tried a ''make dist'' and then e.g., ''cp -a dist/install > > /opt/xen2'', then add appropriate paths to the front of PATH, > > LD_LIBRARY_PATH, PYTHONPATH? > > Works sort of. I have the 2.x versions in /usr now (normal suse > 9.3 rpms), 3.x in /opt/xen3/usr. xend complains that it can''t > start xcs and doesn''t come up. When I start xcs manually first > it works. I''d guess xend tries to start the 2.x version in > /usr/sbin although /opt/xen3/usr/sbin comes first in $PATH ... >yes, that is the case, since in /usr/sbin/xend, we have: XCS_EXEC = "/usr/sbin/xcs" should we execute xcs without the full path? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/30/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 30 May 2005, at 14:22, Gerd Knorr wrote: > > > Is there some easy way to install both 2.x and unstable xen > > tools at the same machine? Seems /usr is hardcoded everythere > > in the tools Makefiles, looks like there is no easy way to put > > them to different paths (say, prefix /opt/xen2 and /opt/xen3) > > :-/ > > Have you tried a ''make dist'' and then e.g., ''cp -a dist/install > /opt/xen2'', then add appropriate paths to the front of PATH, > LD_LIBRARY_PATH, PYTHONPATH? > > ''DESTDIR=/opt/xen2 make install'' also ought to work in a similar way. > > Neither of the above is well-tested, but we would expect them to work. >anyway, there is one problem: what if -stable and -unstable use the same xen0 kernel version? then we cannot have separate directory at /lib/module/<kernel-version> regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 30 May 2005, at 17:00, aq wrote:> yes, that is the case, since in /usr/sbin/xend, we have: > > XCS_EXEC = "/usr/sbin/xcs" > > should we execute xcs without the full path?Perhaps best would be to try with no path, and fall back to /usr/sbin/xcs. I''d definitely take a tested patch to that effect (for both -testing and -unstable). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 30 May 2005, at 17:03, aq wrote:> anyway, there is one problem: what if -stable and -unstable use the > same xen0 kernel version? then we cannot have separate directory at > /lib/module/<kernel-version>Is it not possible to redirect the modutils and module auto-loader to a different path? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> anyway, there is one problem: what if -stable and -unstable use the > same xen0 kernel version? then we cannot have separate directory at > /lib/module/<kernel-version>This is easy: CONFIG_LOCALVERSION="<whatever>" ;) Gerd -- -mm seems unusually stable at present. -- akpm about 2.6.12-rc3-mm3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/31/05, Gerd Knorr <kraxel@suse.de> wrote:> > anyway, there is one problem: what if -stable and -unstable use the > > same xen0 kernel version? then we cannot have separate directory at > > /lib/module/<kernel-version> > > This is easy: CONFIG_LOCALVERSION="<whatever>" ;)yep, i like this solution :-) regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/30/05, Gerd Knorr <kraxel@suse.de> wrote:> > anyway, there is one problem: what if -stable and -unstable use the > > same xen0 kernel version? then we cannot have separate directory at > > /lib/module/<kernel-version> > > This is easy: CONFIG_LOCALVERSION="<whatever>" ;) >Gerd, would be great if you could write a small HOWTO about how to do "parallel install" and put it into docs/. that would be certainly helpful for some people ;-) regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Gorm Hansen
2005-May-31 02:52 UTC
Re: [Xen-devel] stable / unstable parallel install?
Steven Hand wrote:>>Is there some easy way to install both 2.x and unstable xen >>tools at the same machine? Seems /usr is hardcoded everythere >>in the tools Makefiles, looks like there is no easy way to put >>them to different paths (say, prefix /opt/xen2 and /opt/xen3) >>:-/ > > > No easy way that I know of - we typically just use different root > file systems here to ensure that everything is completely separated.What I do is I statically link all the tools (I use vm-tools exclusively), so I don''t have to fiddle with all the /usr/lib symlinks and PYTHON_PATH etc. This allows me to switch versions quickly, or to have several versions installed at the same time. Just Say No to shared libraries and interpreted languages ;-) Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Gerd, would be great if you could write a small HOWTO about how to do > "parallel install" and put it into docs/. that would be certainly > helpful for some people ;-)Still fiddeling to make it work. I''ve deinstalled the rpm with the 2.x stuff in /usr, I have both 2.x and 3.x in non-default locations now, so the 3.x versions can''t attempt to use some 2.x stuff below /usr. Didn''t manage to boot domU so far (neither 2.x nor 3.x). How compatible is the config stuff in /etc/xen? Can that be shared between xen2 and xen3? Or should I better prepare to switch that one as well? Gerd -- -mm seems unusually stable at present. -- akpm about 2.6.12-rc3-mm3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Still fiddeling to make it work. I''ve deinstalled the rpm > with the 2.x stuff in /usr, I have both 2.x and 3.x in > non-default locations now, so the 3.x versions can''t attempt > to use some 2.x stuff below /usr. Didn''t manage to boot domU > so far (neither 2.x nor 3.x). > > How compatible is the config stuff in /etc/xen? Can that be > shared between xen2 and xen3? Or should I better prepare to > switch that one as well?There are options you can specify in xen3 that don''t make parse in xen2, but I think a set of xen2 config files will probably work with xen3. At least, I''d be interested to know if not. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/31/05, Gerd Knorr <kraxel@suse.de> wrote:> > Gerd, would be great if you could write a small HOWTO about how to do > > "parallel install" and put it into docs/. that would be certainly > > helpful for some people ;-) > > Still fiddeling to make it work. I''ve deinstalled the rpm with > the 2.x stuff in /usr, I have both 2.x and 3.x in non-default > locations now, so the 3.x versions can''t attempt to use some 2.x > stuff below /usr. Didn''t manage to boot domU so far (neither > 2.x nor 3.x). > > How compatible is the config stuff in /etc/xen? Can that be > shared between xen2 and xen3? Or should I better prepare to > switch that one as well?yes, looks like -testing''s /etc/xen and -unstable''s /etc/xen are compatible, and i think xen2 could use xen3''s configuration, but not sure about vice versa. at least xen3 has bochsrc, which is not existent in xen2. so i guess it is safer to use xen3''s /etc/xen all the time to support "parallel install". regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/31/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 30 May 2005, at 17:00, aq wrote: > > > yes, that is the case, since in /usr/sbin/xend, we have: > > > > XCS_EXEC = "/usr/sbin/xcs" > > > > should we execute xcs without the full path? > > Perhaps best would be to try with no path, and fall back to > /usr/sbin/xcs. I''d definitely take a tested patch to that effect (for > both -testing and -unstable). >Keir, there is no xcs in -testing. Here is the patch: it tries to execute xcs without full path first, then if there is error, it fallbacks to the default path. Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com> $ diffstat xcs_nopath.diff xend | 15 ++++++++++----- 1 files changed, 10 insertions(+), 5 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > > XCS_EXEC = "/usr/sbin/xcs" > > > > > > should we execute xcs without the full path? > > > > Perhaps best would be to try with no path, and fall back to > > /usr/sbin/xcs. I''d definitely take a tested patch to that > effect (for > > both -testing and -unstable). > > Here is the patch: it tries to execute xcs without full path > first, then if there is error, it fallbacks to the default path.xcs should not be on the path. Christian pointed out that such helper applications should probably live in /usr/libexec/xen Anyone got any objections to moving all such helper applications into /usr/libexec/xen ? We can then have a general overide for the helper application directory. Best, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/1/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > > > > XCS_EXEC = "/usr/sbin/xcs" > > > > > > > > should we execute xcs without the full path? > > > > > > Perhaps best would be to try with no path, and fall back to > > > /usr/sbin/xcs. I''d definitely take a tested patch to that > > effect (for > > > both -testing and -unstable). > > > > Here is the patch: it tries to execute xcs without full path > > first, then if there is error, it fallbacks to the default path. > > xcs should not be on the path. Christian pointed out that such helper > applications should probably live in /usr/libexec/xen >btw, how do you define it "helper application? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> xcs should not be on the path. Christian pointed out that such helper > applications should probably live in /usr/libexec/xen$(prefix)/libexec/xen ;) I think it would be a very good idea to have the install prefix configurable (extra bonus for an environment variable to overwrite this at runtime ;). I can go through the tools build system and try to fix that everythere. Probably it''s needed anyway, I havn''t managed yet to make the 3.x tools work in a non-standard location. xend comes up, xm list & xm dmesg works as well, but booting domU''s doesn''t work. Tested with unpatched xen & xenlinux & tools of course, so this shouldn''t be a hypercall interface issue. With 2.x it works fine. Start script is attached below for reference. BTW: IIRC libexec is deprecated these days, I think arch-specific stuff just goes to lib (including binaries) and non-arch stuff to share. Gerd ==============================[ cut here ]=============================#! /bin/sh ### BEGIN INIT INFO # Provides: xen # Required-Start: $syslog $network # Required-Stop: $syslog $network # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: xen daemon # Description: xen daemon ### END INIT INFO # init script stuff . /etc/rc.status rc_reset # config xen2="/work/bk/xen/xen-2/dist/install" xen3="/work/bk/xen/xen-3/dist/install" # figure where we are running function xen_detect() { local xenprefix if test -f /proc/xen/grant; then echo "Xen 3.0 unstable found" xenprefix="$xen3" elif test -d /proc/xen; then echo "Xen 2.0.x found" xenprefix="$xen2" else echo "running unXen-ified on the bare metal" rm -f /etc/profile.d/xen.sh exit 0 fi # update config cat <<-EOF > /etc/profile.d/xen.sh PATH="$xenprefix/usr/sbin:$xenprefix/usr/bin:\$PATH" LD_LIBRARY_PATH="$xenprefix/usr/lib" PYTHONPATH="$xenprefix/usr/lib/python" export PATH LD_LIBRARY_PATH PYTHONPATH EOF chmod 755 /etc/profile.d/xen.sh } case "$1" in start) xen_detect source /etc/profile.d/xen.sh xcs="$(which xcs 2>/dev/null)" xend="$(which xend 2>/dev/null)" if test -x "$xcs"; then echo -n " starting xcs " startproc $xcs rc_status -v fi if test -x "$xend"; then echo -n " starting xend " $xend start rc_status -v fi ;; stop) xen_detect source /etc/profile.d/xen.sh xcs="$(which xcs 2>/dev/null)" xend="$(which xend 2>/dev/null)" if test -x "$xend"; then echo -n " shutting down xend " $xend stop rc_status -v fi if test -x "$xcs"; then echo -n " shutting down xcs " killall -TERM $xcs rc_status -v fi ;; restart) $0 stop $0 start rc_status ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 ;; esac rc_exit _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > xcs should not be on the path. Christian pointed out that > such helper > > applications should probably live in /usr/libexec/xen > > btw, how do you define it "helper application?Well, users would not want to invoke it directly. It''s not useful to have on the path. I''d much rather continue to have a single script that''s run to start all the necessary components as per a configuration file, rather than exposing them all individually to users. If as Gerd says /usr/libexec/xen is deprecated (though I note that it is still used by a bunch of stuff in FC3), then what do we go for? /usr/lib/xen , /usr/share/xen or /usr/opt/xen ? Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> If as Gerd says /usr/libexec/xen is deprecated (though I note that it is > still used by a bunch of stuff in FC3),See http://www.pathname.com/fhs/> then what do we go for? > /usr/lib/xen , /usr/share/xen or /usr/opt/xen ?/usr/lib/xen is the correct one I''d say. Maybe /usr/lib/xen/bin to separate it from other xen stuff below /usr/lib/xen. /usr/share is for architecture-independent stuff such as documentation and data, but certainly not binaries. Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/1/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > > > xcs should not be on the path. Christian pointed out that > > such helper > > > applications should probably live in /usr/libexec/xen > > > > btw, how do you define it "helper application? > > Well, users would not want to invoke it directly. It''s not useful to > have on the path. > > I''d much rather continue to have a single script that''s run to start all > the necessary components as per a configuration file, rather than > exposing them all individually to users. > > If as Gerd says /usr/libexec/xen is deprecated (though I note that it is > still used by a bunch of stuff in FC3), then what do we go for? > /usr/lib/xen , /usr/share/xen or /usr/opt/xen ? >so no decision has been made on this problem? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > If as Gerd says /usr/libexec/xen is deprecated (though I > note that it > > is still used by a bunch of stuff in FC3), then what do we go for? > > /usr/lib/xen , /usr/share/xen or /usr/opt/xen ? > > > > so no decision has been made on this problem?I think we decided on having a hierarchy of helper binaries and other files under /usr/lib/xen/ e.g. /usr/lib/xen/bin/ Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 2005-06-04 at 23:57 +0900, aq wrote:> On 6/1/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote: > > If as Gerd says /usr/libexec/xen is deprecated (though I note that it is > > still used by a bunch of stuff in FC3), then what do we go for? > > /usr/lib/xen , /usr/share/xen or /usr/opt/xen ? > > > > so no decision has been made on this problem?/usr/lib/xen would be the place for non-path executables, according to the FHS. Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel