SUSE Conversations


Making CommVault SP2 Galaxy work on SLES 10 SP1

variia

By: variia

January 30, 2008 12:07 am

Reads:256

Comments:3

Rating:0

This tip presents a solution to make CommVault 7SP2 data migration running properly on SLES 10 SP1.

For CommVault data migration we need DMAPI and XFS support coupled in the kernel which is officially built in/supported on SLEx 10 SP1 Linux, apparently it’s the only commercially supported Linux with this option. (Thanks!)

When we mount the xfs partition with this option drivers (kernel modules) get loaded in automatically:

sles10sp1:~ # grep xfs /etc/fstab
/dev/disk/by-uuid/841a8967-d904-427c-9042-b679f2a9af0e /data xfs logbufs=8,dmapi,mtpt=/data,quota,gquota 1 2

sles10sp1:~ # mount /data

sles10sp1:~ # lsmod | grep dmapi
xfs_dmapi 33688 1
dmapi 53672 1 xfs_dmapi,[permanent]
xfs 580728 3 xfs_quota,xfs_dmapi

The problem is that Commvault (Galaxy) looks for a device under /dev named “xfs_dmapi” which is named “dmapi” in SLEx 10 SP1. It’s not a big deal, we can just create a symbolic link to it but it will disappear at next reboot due to /dev is “tmpfs” since SP1!

There are plenty of ways to solve this problem but which is the one which won’t get overwritten by updates, portable and really the right way of doing this?

udev for the rescue! udev manages devices so we will create a simple rule to instruct udev to re-create the symbolic link every time the system boots.

sles10sp1:~ # cat /etc/udev/rules.d/999-udev-dmapi-commvault.rules
RUN+="/bin/ln -s /dev/dmapi /dev/xfs_dmapi"

Usually rules are more complex, describing which subsystem, which driver, module, etc. we are about to alter but this time we really do not need anything special just run a simple command. I decided to run the command last in the rules directory hence the numbering is high.

To read a bit more about this:
http://reactivated.net/writing_udev_rules.html

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: ,
Categories: SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

3 Comments

  1. By:billdo

    CommVault File Archiver / Data Migrator is the only part of CommVault Galaxy aka Simpana that uses the XFS filesystem with the DMAPI hooks. We’ve been experiencing EXTREME performance problems to the point that the product is useless. This has existed since our initial install a few months ago.

    Is anyone here having the same problem? I’m assuming yes, because we’ve been told by CommVault support that the problem is because of the DMAPI interface. Right now we can only get recalls using File Archiver to perform at 20% of the rated speed of the drive. Yes, that’s correct, 20%.

    CommVault has had their top engineers and even their software developers looking at our environment for a month. Any one here having the same problem since Commvault has left us holding the bag? We’re running SLES 10 with the latest CommVault Simpana patches on all components. Perhaps someone has some sysctl changes that we can implement until CommVault starts really supporting their software on Linux?

    Thanks for any help!
    Bill Donnington

  2. By:cscottselero

    Thanks for the post!
    One thing I came across while implementing XFS for File Archiver:

    Don’t forget to modify /etc/sysconfig/sysctl

    DMAPI_PROBE=”yes”

    Chris

  3. By:variia

    Thanks for the hint!

    Ivan

Comment

RSS