stable / unstable parallel install?

stable / unstable parallel install?

[Gerd Knorr]

  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

Re: stable / unstable parallel install?

[Steven Hand]

> 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.

Re: stable / unstable parallel install?

[Keir Fraser]

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

Re: stable / unstable parallel install?

[Gerd Knorr]

> > 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

Re: stable / unstable parallel install?

[Gerd Knorr]

> 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

Re: stable / unstable parallel install?

[aq]

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

Re: stable / unstable parallel install?

[aq]

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

Re: stable / unstable parallel install?

[Keir Fraser]

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

Re: stable / unstable parallel install?

[Keir Fraser]

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

Re: stable / unstable parallel install?

[Gerd Knorr]

> 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

Re: stable / unstable parallel install?

[aq]

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

Re: stable / unstable parallel install?

[aq]

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

Re: stable / unstable parallel install?

[Jacob Gorm Hansen]

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

Re: stable / unstable parallel install?

[Gerd Knorr]

> 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

RE: stable / unstable parallel install?

[Ian Pratt]

 
> 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

Re: stable / unstable parallel install?

[aq]

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

Re: stable / unstable parallel install?

[aq]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

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(-)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xcs_nopath.diff --]
[-- Type: text/x-patch; name="xcs_nopath.diff", Size: 1486 bytes --]

===== tools/misc/xend 1.23 vs edited =====
--- 1.23/tools/misc/xend	2005-05-25 03:53:31 +09:00
+++ edited/tools/misc/xend	2005-06-01 16:25:06 +09:00
@@ -27,8 +27,10 @@
 
 XCS_PATH    = "/var/lib/xen/xcs_socket"
 XCS_EXEC    = "/usr/sbin/xcs"
+XCS_NP_EXEC = "xcs"    # xcs with no path
 XCS_PIDFILE = "/var/run/xcs.pid"
 XCS_ARGS    = (XCS_EXEC, "-p", XCS_PIDFILE)
+XCS_NP_ARGS = (XCS_NP_EXEC, "-p", XCS_PIDFILE)   # execute xcs with no path
 
 # add fallback path for non-native python path installs if needed
 sys.path.append('/usr/lib/python')
@@ -92,12 +94,15 @@
             if not os.path.isdir(os.path.dirname(XCS_PATH)):
                 os.makedirs(os.path.dirname(XCS_PATH))
             try:
-                os.execvp(XCS_EXEC, XCS_ARGS)
+                os.execvp(XCS_NP_EXEC, XCS_NP_ARGS) # execute xcs with no path
             except:
-                hline()
-                msg("Tried to start xcs, but failed. Is it installed?")
-                hline()
-                raise CheckError("couldn't start xcs")
+                try:
+                    os.execv(XCS_EXEC, XCS_ARGS)    # fallback to execute xcs in default path
+                except:
+                    hline()
+                    msg("Tried to start xcs, but failed. Is it installed?")
+                    hline()
+                    raise CheckError("couldn't start xcs")
         if (not xcs_running()):
             hline()
             msg("Failed to start the control interface switch.")

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: stable / unstable parallel install?

[Ian Pratt]

 
> > > 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

Re: stable / unstable parallel install?

[aq]

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

Re: stable / unstable parallel install?

[Gerd Knorr]

  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

RE: stable / unstable parallel install?

[Ian Pratt]

> > 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

Re: stable / unstable parallel install?

[Gerd Knorr]

> 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

Re: stable / unstable parallel install?

[aq]

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

RE: stable / unstable parallel install?

[Ian Pratt]

 
> > 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

Re: stable / unstable parallel install?

[Rusty Russell]

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