Xen devel - Dec 2006 - running multiple version of Xen on a single machine

With a limited number of physical machines and many distro versions to support
I would find it really handy if there was a way to run multiple Xen versions in
parallel (one at a time obviously) on any such system. This implies that I
don''t
want to install Xen tools (as they would otherwise overwrite the
distro''s original
package), which in turn implies that there must not be absolute path names in
any of the tools/scripts unless there is a way to override these.

It would in my opinion be easiest if each affected tool determined where it was
run from, subtract its install location and use the remaining path as the
pseudo-root to find everything else. Alternatively, a command line option might
be used, but I''d like auto detection much better.

Taking care of PATH, LD_LIBRARY_PATH, and PYTHONPATH in order to be able
to run the tool(s) in the first place would obviously need to be left to the
individual user, but can be easily done in a wrapper script.

Opinions? Has anyone already done this in a different way?

Jan

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

Jan Beulich wrote:
> With a limited number of physical machines and many distro versions to
support
> I would find it really handy if there was a way to run multiple Xen
versions in
> parallel (one at a time obviously) on any such system. This implies that I
don''t
> want to install Xen tools (as they would otherwise overwrite the
distro''s original
> package), which in turn implies that there must not be absolute path names
in
> any of the tools/scripts unless there is a way to override these.
> 
> It would in my opinion be easiest if each affected tool determined where it
was
> run from,
Do you mean by examining CWD and argv[0]?

My fear would be that that would break a lot of things that use special 
tools to launch daemons.

I suspect we need to move to a PREFIX model.  Not sure the best way to 
propagate something like that throughout Xen.

It''s further complicated by the fact that Xend depends on the implicit 
prefix in a number of places (to launch xenconsole, 
xc_linux_{save,restore}, qemu-dm, etc.).

Regards,

Anthony Liguori

  subtract its install location and use the remaining path as
the
> pseudo-root to find everything else. Alternatively, a command line option
might
> be used, but I''d like auto detection much better.
> 
> Taking care of PATH, LD_LIBRARY_PATH, and PYTHONPATH in order to be able
> to run the tool(s) in the first place would obviously need to be left to
the
> individual user, but can be easily done in a wrapper script.
> 
> Opinions? Has anyone already done this in a different way?
> 
> Jan

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

Hmm... would running your tests (with xend & friends) inside a chroot
be sufficient?  I realize it''s a bit of a pain to set one up, but once
set up, you should be able to switch from one set of tools to another
pretty quickly.

 -George

On 12/6/06, Anthony Liguori <aliguori@linux.vnet.ibm.com>
wrote:
> Jan Beulich wrote:
> > With a limited number of physical machines and many distro versions to
support
> > I would find it really handy if there was a way to run multiple Xen
versions in
> > parallel (one at a time obviously) on any such system. This implies
that I don''t
> > want to install Xen tools (as they would otherwise overwrite the
distro''s original
> > package), which in turn implies that there must not be absolute path
names in
> > any of the tools/scripts unless there is a way to override these.
> >
> > It would in my opinion be easiest if each affected tool determined
where it was
> > run from,
>
> Do you mean by examining CWD and argv[0]?
>
> My fear would be that that would break a lot of things that use special
> tools to launch daemons.
>
> I suspect we need to move to a PREFIX model.  Not sure the best way to
> propagate something like that throughout Xen.
>
> It''s further complicated by the fact that Xend depends on the
implicit
> prefix in a number of places (to launch xenconsole,
> xc_linux_{save,restore}, qemu-dm, etc.).
>
> Regards,
>
> Anthony Liguori
>
>   subtract its install location and use the remaining path as the
> > pseudo-root to find everything else. Alternatively, a command line
option might
> > be used, but I''d like auto detection much better.
> >
> > Taking care of PATH, LD_LIBRARY_PATH, and PYTHONPATH in order to be
able
> > to run the tool(s) in the first place would obviously need to be left
to the
> > individual user, but can be easily done in a wrapper script.
> >
> > Opinions? Has anyone already done this in a different way?
> >
> > Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> "George Dunlap " <dunlapg@umich.edu> 08.12.06 21:11
>>>
>Hmm... would running your tests (with xend & friends) inside a chroot
>be sufficient?  I realize it''s a bit of a pain to set one up, but
once
>set up, you should be able to switch from one set of tools to another
>pretty quickly.
That might work (minus the xenstored issue described earlier, and minus
any potential similar issues not identified, yet), but I really think working
around the problem is not the right way - fixing the dependencies would
be far more appropriate.

Jan

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