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: