Xen - Revision history

Luc at 10:58, 5 March 2008

2008-03-05T10:58:28Z

Psap at 21:26, 31 May 2007

2007-05-31T21:26:55Z

Psap at 21:25, 31 May 2007

2007-05-31T21:25:39Z

Psap: Sybase and Xen moved to Xen

2007-05-31T21:23:44Z

Sybase and Xen moved to Xen

Psap at 21:21, 31 May 2007

2007-05-31T21:21:14Z

Psap at 21:20, 31 May 2007

2007-05-31T21:20:05Z

Psap: /* Throubleshooting Replication Server */

2006-05-31T19:46:18Z

‎Throubleshooting Replication Server

Psap at 19:42, 31 May 2006

2006-05-31T19:42:22Z

Psap at 22:37, 29 May 2006

2006-05-29T22:37:24Z

Psap at 22:30, 29 May 2006

2006-05-29T22:30:37Z

@@ Line 6: / Line 6: @@
 == Notes ==
 * ASE 15.0 works OK but sofar only limited tests have been performed.
-* Replication Server 15.0 is a problem. For performance reasons Xen uses its own mechanism to handle "thread-local storage" (http://en.wikipedia.org/wiki/Thread_Local_Storage) in stead of the libraries in /lib/tls. When you install a replication server and a  stable device cannot be created (or only a single 16Kb allocation is made) you hit the tls bug. See below for a description to identify this issue in more detail and how to use the standard /lib/tls libraries. Further research is now focussed on the performance impact of using thread local storage from /lib/tls in combination with Xen.
+* Replication Server 15.0 is not a good combination with a 32bit xen-hypervisor (with a 64bit hypervisor and dom0, there is no issue, even in a 32bit domU running on the 64 bit hypervisor/kernel). Replication Server needs the TLS functionality. For performance reasons Xen uses its own mechanism to handle "thread-local storage" (http://en.wikipedia.org/wiki/Thread_Local_Storage) in stead of the libraries in /lib/tls. When you install a replication server and a  stable device cannot be created (or only a single 16Kb allocation is made) you hit the tls bug. See below for a description to identify this issue in more detail and how to use the standard /lib/tls libraries. Further research is now focussed on the performance impact of using thread local storage from /lib/tls in combination with Xen.
-== Throubleshooting Replication Server ==
+=== Throubleshooting Replication Server ===
 Use the Linux ldd utility to check if the repserver binary (located in $SYBASE/$SYBASE_REP/bin) picks up the right libraries from /lib/tls. Just do a "ldd ./repserver" and check the output. You should get this: (ignore the hexadecimal numbers)

← Older revision		Revision as of 21:26, 31 May 2007
Line 40:		Line 40:

	Good luck!		Good luck!
		+
		+
		+	[[category:ASE]]
		+	[[category:RepServer]]

← Older revision		Revision as of 21:25, 31 May 2007
Line 40:		Line 40:

	Good luck!		Good luck!
−
−
−	~~[[category:ASE]]~~
−	~~[[category:RepServer]]~~

← Older revision		Revision as of 21:21, 31 May 2007
Line 40:		Line 40:

	Good luck!		Good luck!
		+
		+
		+	[[category:ASE]]
		+	[[category:RepServer]]

@@ Line 1: / Line 1: @@
-I'm currently (may/june 2006) doing some research on the usability of ASE and Replication Server with Xen virtualization (http://www.xensource.com) on Linux systems.
+I'm using Xen virtualization (http://www.xensource.com) to run my ASE and Replication Servers on Linux systems. Here are some real life experiences:
-== Quick Notes ==
+==General==
 * ASE 15.0 works OK but sofar only limited tests have been performed.
 * Replication Server 15.0 is a problem. For performance reasons Xen uses its own mechanism to handle "thread-local storage" (http://en.wikipedia.org/wiki/Thread_Local_Storage) in stead of the libraries in /lib/tls. When you install a replication server and a  stable device cannot be created (or only a single 16Kb allocation is made) you hit the tls bug. See below for a description to identify this issue in more detail and how to use the standard /lib/tls libraries. Further research is now focussed on the performance impact of using thread local storage from /lib/tls in combination with Xen.
 == Throubleshooting Replication Server ==

← Older revision	Revision as of 21:23, 31 May 2007
(No difference)

@@ Line 22: / Line 22: @@
 When you get something else do one of the following, depending on your situation:
-* When you have disabled tls in the process of setting up a Xen domain, reverse this step. Xen asks you to rename the tls directory in /lib to something like "tls.disabled". Rename the directory back to tls, then reboot the Xen domain.
+* When you have disabled tls in the process of setting up a Xen domain, reverse this step. Xen asks you to rename the tls directory in /lib to something like "tls.disabled". Rename the directory back to tls.
-* Check the libraries in /lib/i686. Go to /lib/i686 and rename the files libc.so.6, libm.so.6, libpthread.so.0 and librt.so.1 to something else. This might not be the best solution for everybody since these files are soft links to the actual libraries, but for repserver it works (sorry, I'm not a Linux guru). No reboot is needed since these libraries are loaded on demand.
+* Check the libraries in /lib/i686. Go to /lib/i686 and rename the files libc.so.6, libm.so.6, libpthread.so.0 and librt.so.1 to something else. This might not be the best solution for everybody since these files are soft links to the actual libraries, but for repserver it works (sorry, I'm not a Linux guru). No reboot is needed since the libraries are loaded on demand.
 * It still doesn't work? Send me an e-mail.
@@ Line 37: / Line 37: @@
   ***************************************************************
   ***************************************************************

@@ Line 2: / Line 2: @@
 * ASE 15.0 works OK but sofar only limited tests have been performed.
-* Replication Server 15.0 is a problem. It seems that the problem is related to "tread-local storage" (see http://en.wikipedia.org/wiki/Thread_Local_Storage). For performance reasons Xen does not use the standard libraries located in /lib/tls/* but uses it's own mechanism to handle thread-local storage. For a user of replication server the problem appears that stable devices cannot be created (in fact only a single 16Kb allocation is done). All research is now focussed on the impact of using thread local storage from /lib/tls and it's performance impact.
+* Replication Server 15.0 is a problem. It seems that the problem is related to "thread-local storage" (see http://en.wikipedia.org/wiki/Thread_Local_Storage). For performance reasons Xen does not use the standard libraries located in /lib/tls but uses it's own mechanism to handle thread-local storage. For a user of replication server it appears that stable devices cannot be created (in fact only a single 16Kb allocation is done). Research is now focussed on the impact of using thread local storage from /lib/tls in combination with Xen and it's performance impact.
 Feedback on this subject is very welcome. mailto:peter@petersap.nl

← Older revision		Revision as of 22:30, 29 May 2006
Line 4:		Line 4:
	* Replication Server 15.0 is a problem. It seems that the problem is related to "tread-local storage" (see http://en.wikipedia.org/wiki/Thread_Local_Storage). For performance reasons Xen does not use the standard libraries located in /lib/tls/* but uses it's own mechanism to handle thread-local storage. For a user of replication server the problem appears that stable devices cannot be created (in fact only a single 16Kb allocation is done). All research is now focussed on the impact of using thread local storage from /lib/tls and it's performance impact.		* Replication Server 15.0 is a problem. It seems that the problem is related to "tread-local storage" (see http://en.wikipedia.org/wiki/Thread_Local_Storage). For performance reasons Xen does not use the standard libraries located in /lib/tls/* but uses it's own mechanism to handle thread-local storage. For a user of replication server the problem appears that stable devices cannot be created (in fact only a single 16Kb allocation is done). All research is now focussed on the impact of using thread local storage from /lib/tls and it's performance impact.

−	~~All feedback~~ on this subject is very welcome. mailto:peter@petersap.nl	+
		+	Feedback on this subject is very welcome. mailto:peter@petersap.nl