Difference between revisions of "Xen"

Latest revision as of 11:58, 5 March 2008

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:

General

When you use raw devices and create those from Domain-0 they become visible in the guest domain as owned by root. When you chown these devices to for instance the sybase user, the ownership will be reversed to root after a reboot. The solution for this is to execute a script from /etc/init.d at boottime that sets the right ownership/permissions.

Notes

• ASE 15.0 works OK but sofar only limited tests have been performed.
• 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

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)

libnsl.so.1 => /lib/libnsl.so.1 (0x008b4000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c95000)
libm.so.6 => /lib/tls/libm.so.6 (0x00b7f000)
libdl.so.2 => /lib/libdl.so.2 (0x00ba4000)
libc.so.6 => /lib/tls/libc.so.6 (0x00a53000)
librt.so.1 => /lib/tls/librt.so.1 (0x00736000)
/lib/ld-linux.so.2 (0x00a3a000)

Note: your output might also mention linux-gate.so.1, just ignore this.

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

The setup if correct if you see this during booting of the domain:

***************************************************************
***************************************************************
** WARNING: Currently emulating unsupported memory accesses  **
**          in /lib/tls libraries. The emulation is very     **
**          slow. To ensure full performance you should      **
**          execute the following as root:                   **
**          mv /lib/tls /lib/tls.disabled                    **
***************************************************************
***************************************************************

Good luck!