Migrating a native UCS installation to UVMM
From Univention Wiki
Contents |
Restrictions
The following article describes how to migrate a standard installation of UCS and must be adapted to each individual setting. However, the following restrictions apply:
Live migration
If the server, that is to be migrated, has to be accessed during the process, special care has to be taken of application data. This, however, would go beyond the scope of this article. If desired, Univention offers advice for such an scenario.
Migration of a DC Master
If the DC Master does not hold data or printservices that need to be migrated, the installation of a DC Backup and promotion to a DC Master is preferred to migrating the DC Master. The promotion is done with the folling command on the DC Backup:
univention-backup2master
If this is not possible and more servers in addition to the DC Master need to be migrated, the DC Master must be saved and reinstated as first system. Again, Univention offers advice if such an scenario is required.
Preparations
Besides the UCS system, that will be migrated, and a working installation of UVMM, a Linux Live-CD with LVM (i.e. SystemRescueCd support is needed.
Copying the harddrive
To transfer a native UCS installation into a UVMM instance, the harddrive is saved as an image file which is then used by UVMM.
For this, the system must be booted with the Live-CD. The installed harddrives can be identified by using the following command:
fdisk -l
To transfer the system, it is recommended using an external harddrive or USB key:
dd if=/dev/sda of=/mnt/usb/ucs.raw
Hint: When combining the commands dd and scp, the image can be copied to the UVMM system and the need for an intermediate storage is omitted.
When the copy process is finished, the system can be shut down.
The image is saved as raw file and can now be used as a virtual harddrive with UVMM. If additional features, i.e. creation and usage of snapshots, is desired, the image file must be converted to a qcow2 file.
Creation of a virtual instance
The raw image is copied to /var/lib/libvirt/images on the UVMM host.
If KVM is used for virtualization, and advanced features should be used, then the image must be converted to a qcow2 file:
cd /var/lib/libvirt/images/ qemu-img convert -f raw -O qcow2 ucs.raw ucs.qcow2
Afterwards, a new virtual instance must be created, using the UCS 2.4 profile. The raw or qcow2 file must be assigned as harddrive. After starting the virtual instance, the system boots up.
Migration by copying the core files
To transfer a native UCS installation into a UVMM instance, its harddrive is saved to a file and then copied into an existing, already virtualized, UCS installation.
Using the following script, all files and ACLs are saved on the server:
#!/bin/sh # export BACKUPPATH=<my-Backup-Path> mkdir -p $BACKUPPATH ionice -c 3 nice -n 20 tar cvfj $BACKUPPATH/daten.tar.bz2 --numeric-owner --atime-preserve -X <exclude> --exclude=$BACKUPPATH / getfacl --skip-base -RP / > $BACKUPPATH/acl
Please note, that the directory <my-Backup-Path> has enough free space to hold the backup. Furthermore, the file <exclude> must be created, containing directories that are not to be saved with the backup. The following directories must be included:
/sys /proc /dev /dev/shm /dev/pts /lib/init/rw /var/lib/nfs/rpc_pipefs /opt/pcbin
It is recommended to include the following directories as well:
/var/backups /var/cache/apt/archives /var/lib/univention-repository /var/lib/univention-ldap/replog /var/lib/opsi/products /var/log /var/spool/squid /var/tmp /var/univention-backup /tmp
If necessary, the script must be made executable prior executing it as root user:
chmod +x script
Migration into a virtual system
First a new VM is created, profile Other (64 Bit). The harddrive must at least match the source systems size and quantity. Furthermore, a second harddrive must be created, at least the size of the backup file and the Live-CD must be mounted in the virtual CD-ROM drive.
During the boot up of the Live-CD, the old server's architecture should be loaded. If unsure, take the 64 bit version.
After the system booted, make sure the system has an IP address and the SSH daemon is started.
Using the command
fdisk /dev/sda
it is possible to partition the harddrive. In a UCS standard installation, UCS paritions a 256 MB /boot partition, a 2 GB swap partition and the available rest is used by the LVM. Using the following squence in fidsk, a similar setup can be installed on /dev/sda:
n -> p -> 1 -> -> +256M n -> p -> 2 -> -> +2G t -> 2 -> 82 n -> p -> 3 -> -> t -> 3 -> 8e w
Now the Logical Volume Groups must be created on the harddrive. In an UCS standard installation, one VG exists with one volume. This can be recreated with the folling command:
pvcreate /dev/sda3 vgcreate vg_ucs /dev/sda3 lvcreate -l 100%VG -n rootfs vg_ucs
Now the /boot and LVM partition can be formatted with the ext2 respectively ext4, and the swap partion can be created:
mke2fs /dev/sda1 mkswap /dev/sda2 mke2fs -j /dev/mapper/vg_ucs-rootfs
The same steps must be conducted for the second harddrive. whereas an ext2 partition is sufficient:
fdisk /dev/sdb n -> p -> 1 -> -> w mke2fs /dev/sdb1
Now the the harddisks are ready to be mounted to the following locations:
mount /dev/vg_ucs/rootfs /mnt/custom -o acl mkdir /mnt/custom/boot mount /dev/sda1 /mnt/custom/boot -o acl mount /dev/sdb1 /mnt/backup
Copying the files to the new system
Now the actual migration can start. Copy the backup files from the hardware system to the virtual system:
root@hardwaresystem# scp <my-Backup-Path>/daten.tar.bz2 root@<target host>:/mnt/backup/ root@hardwaresystem# scp <my-Backup-Path>/acl root@<target host>:/mnt/backup/
The files can now be extracted from the archive:
cd /mnt/custom tar xvjp --atime-preserve --numeric-owner -f /mnt/backup/system-dump.tar.bz2 -C ./
All excluded directories must be created:
mkdir dev proc sys tmp home root mkdir -p shares/home var/log var/lib/univention-repository lib/init/rw var/cache/apt/archives/partial chmod 777 tmp
Finally the ACLs must be copied to the new environment so they can be restored later:
cp /mnt/backup/acl /mnt/custom/tmp/acl
Chroot into the system
After the folder structure is created, the system directories must be mounted into the new environment:
mount -o bind /proc /mnt/custom/proc mount -o bind /dev /mnt/custom/dev mount -o bind /sys /mnt/custom/sys
Now the new environment can be accessed by using chroot:
chroot /mnt/custom /bin/bash source /etc/profile
The ACLs must now be restored:
setfacl --restore=/tmp/acl
Now the Grub bootloader must be initialized:
grub root (hd0,0) setup (hd0) quit
Now some more directories must be created while being in the chroot environment and permissions must be set:
cd /var/log mkdir munin apache2 univention postgresql news apt chown www-data apache2 chown postgres postgresql touch wtmp chown root:utmp wtmp mkdir /var/lib/nfs/rpc_pipefs
If necessary, the /etc/fstab file must be edited to reflect the actual positions for /boot and the swap partition:
#For boot: /dev/sda1 /boot ext3 defaults,acl 0 0 #For swap: /dev/sda2 none swap sw 0 0
Now exit the chroot environment and umount the harddrives:
exit cd /mnt/ umount custom/proc umount custom/dev umount custom/sys umount custom/boot umount custom umount backup
After a reboot the system is ready to be used.
