From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: running multiple version of Xen on a single machine Date: Wed, 06 Dec 2006 11:02:49 -0600 Message-ID: <4576F7B9.6090404@linux.vnet.ibm.com> References: <4576B574.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4576B574.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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