Clone DB2 10g FC23 install to a virtual machine (FC23 or RHEL7)

By | February 8, 2017

I wanted to move my test db2 installation based on a Fedora Core 23 to a RHEL7 virtual machine without having to reinstall everything and not lose any data. This is in fact cloning my test environment database.
This is not an easy task as is not officially supported by IBM but the beauty of Linux is that you know where all your files are so cloning an installation is possible.

STEP 1: Create a new RHEL7 VM

In my case I already have a developer RHEL7 VM so I created a clone. Make sure you have enough space in the VM if your database has data in it. I had to extend the VM disk to 50GB.

STEP 2: Clone the db2 users

First I looked at all the users created by db2 installation and cloned them in the VM.

As root in the VM do:

useradd db2das1
useradd db2fenc1
useradd db2inst1

STEP 3: Clone db2 binaries and instance installation

As root in the originating machine do:

rsync -avz -e "ssh" --progress /var/db2
rsync -avz -e "ssh" --progress /opt/ibm
rsync -avz -e "ssh" --progress /home/db2das1
rsync -avz -e "ssh" --progress /home/db2fenc1
rsync -avz -e "ssh" --progress /home/db2inst1

Where is the IP of the VM.

STEP 4: Check the db2 parameters and add the missing ones
In the original machine do as db2inst1:

[db2inst1@localhost ~]$ db2set -all
[g] DB2SYSTEM=localhost.localdomain
[g] DB2INSTDEF=db2inst1
[g] DB2ADMINSERVER=db2das1

Then the same in the VM and compare the entries. Add eny missing entries with db2set

STEP 5: Add the db2 instance service to /etc/services

Edit /etc/services and add the following line to the end

db2c_db2inst1 50000/tcp # DB2 connection service

STEP 5: Open listener port
In the firewall of the VM open port 50000 for TCP.

Still not OK I was trying to connect from dbvis and getting always

   Error Code: -1639
   SQL State: 08001

According to IBM

The database server was unable to perform authentication because security-related database manager files on the server do not have the required operating system permissions.

and see

STEP 6: Reinitialize the instance
So according to the above we have to reinitialize the instance because some permissions have been changed. This is not surprising because we just cloned the DB.
Very important issue as db2inst1 a db2stop first to stop the instance. Only after that it can be updated.

[root@test1 instance]# pwd
[root@test1 instance]# ./db2iupdt -k db2inst1
DBI1446I  The db2iupdt command is running, please wait.

DB2 installation is being initialized.

 Total number of tasks to be performed: 4 
Total estimated time for all tasks to be performed: 309 second(s) 

Task #1 start
Description: Setting default global profile registry variables 
Estimated time 1 second(s) 
Task #1 end 

Task #2 start
Description: Initializing instance list 
Estimated time 5 second(s) 
Task #2 end 

Task #3 start
Description: Configuring DB2 instances 
Estimated time 300 second(s) 
Task #3 end 

Task #4 start
Description: Updating global profile registry 
Estimated time 3 second(s) 
Task #4 end 

The execution completed successfully.

For more information see the DB2 installation log at "/tmp/db2iupdt.log.23763".
DBI1070I  Program db2iupdt completed successfully.

Note: It is very important to copy /var/db2 from old machine to the VM. Before I did that a lot of the global variables where missing when listing them with db2set -all and db2iupdt was complaining that db2inst1 does not exist.

STEP 7: Restart the instance
As db2inst1 user issue a db2start to restart the instance and the listener.
All done.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.