Migrating an LDAP server running OpenLDAP on Debian Jessie from VirtualBox to Hyper-V

Published in

NordicDev

7 min readNov 28, 2017

VirtualBox is an awesome piece of software. Free, easy to use, cross platform, cooks, folds laundry, mows the lawn. What more could you ask from a hypervisor?

Several years ago, for my personal projects, I dove in to VirtualBox. It fit the bill — I wanted to have a product that would run on my primary desktop (Windows), some play around boxes (Linux), and that could deal with my switching OS’s every few years. Speed up to now, and I’m running almost all of my personal projects and servers on VirtualBox. This is fine and dandy, until it isn’t.

At work, we’re using Hyper-V for all of our hypervisors. This is also a great product. I’ve been enjoying using it more and more as we’ve been using it more, which is nice. I’m so comfortable using Hyper-V that I now prefer it over VirtualBox.

So, now that I prefer Hyper-V over VirtualBox, time to switch over my personal projects to Hyper-V. This way I can take advantage of some of the fancy new learning I’ve done from work, and copy our backup and disaster recovery processes. You know, because my family’s photo website is really important!

Most of my machines are running Debian Jessie. This makes the backup and restore process pretty painless. I’ll break it down into the following steps:

Create the new VM in Hyper-V (vm-new for short)
In the old VM (vm-old for short), SSH into vm-new
On both VMs, install apt-clone
Copy the apt-clone package from vm-old to vm-new
On vm-new, restore the packages using apt-clone
While the restore is rocking, copy over any necessary config files, databases, and ASCII art from vm-old to vm-new
Once the restore is complete, restore any databases, if necessary
Power off vm-old, reboot vm-new, cross fingers

In this example I’m moving over my LDAP server. I have the luxury of being able to have my LDAP server offline for the duration of this migration, which may not be a luxury you have. If that’s the case, you are probably going to want to modify things here quite a bit. Let’s get started!

Create the new VM in Hyper-V (vm-new for short)

I keep a base install image of operating systems I use. This isn’t the best way to go about it, but it works for me for now. Since my ldap box is running Debian Jessie, that’s what I’m going to use. We’ll use PowerShell to import the base image into a new VM. On the host running Hyper-V, open up PowerShell and use the following cmdlet to create a new VM

PS C:\Users\Administrator> Import-VM -Copy -Path "D:\Hyper-V Imports\BASE_DebianJessie\Virtual Machines\C443C11E-D113-423-3DB5-063271B6F740.vmcx" -GenerateNewId

Once that’s done, we need to change the name and the VHD filename to reflect the new server. The name of the imported VM is BASE_DebianJessie, and the new name is going to be LIVE_ldap The following cmdlet will rename our newly imported VM:

PS C:\Users\Administrator> Rename-VM BASE_DebianJessie -NewName LIVE_ldap

Now let’s rename the VHD file. The path to the existing VHD for the newly renamed LIVE_ldap VM is D:\Hyper-V\Virtual Disks\BASE_DebianJessie.vhdx, and the new VHD will be called D:\Hyper-V\Virtual Disks\LIVE_ldap.vhdx. Let’s use PowerShell again

PS C:\Users\Administrator> Rename-Item -Path "D:\Hyper-V\Virtual Disks\BASE_DebianJessie.vhdx" -NewName "D:\Hyper-V\Virtual Disks\LIVE_ldap.vhdx"

Now let’s update the hard disk on the new VM, using the newly renamed VHD file. We’ll actually remove the old VHD (which no longer exists), and then add in the VHD we renamed. Since the base image VM I use has only one hard drive, this is made pretty easy by using the Get-VMHardDiskDrive cmdlet.

PS C:\Users\Administrator> Get-VMHardDiskDrive -VMName LIVE_ldap | Remove-VMHardDiskDrive
PS C:\Users\Administrator> Add-VMHardDiskDrive -VMName LIVE_ldap -Path "D:\Hyper-V\Virtual Disks\LIVE_ldap.vhdx"

As the last piece of tinkering with the VM settings, we’re going to set the VM to use 2048MB of RAM, and set the VM to have 2 virtual processors.

PS C:\Users\Administrator> Set-VMMemory -VMName LIVE_ldap -StartupBytes 2GB
PS C:\Users\Administrator> Set-VM -VMName LIVE_ldap -ProcessorCount 2

Let’s power it on! I have my base image set to grab an IP address from the DHCP server, so once it’s up I’ll connect and grab the IP address.

PS C:\Users\Administrator> Start-VM LIVE_ldap

In the old VM (vm-old for short), SSH into vm-new

This is pretty simple. SSH to vm-old, and from here, SSH into vm-new. I’m using tmux on vm-old, so I have a few shells open on vm-old, and another shell open on vm-new in the same tmux session. This makes rapidly switching back and forth pretty painless. I’m also going to open up an SFTP session from vm-old to vm-new here as well.

Here’s a quick screenshot of what my tabs look like in tmux at this point. Remember, this is on vm-old

0 is su on vm-old, as is 1. 2 is sftp from vm-old to vm-new, and 3 is an ssh session to vm-new (in which I’ve sudo’d to root).

On both VMs, install apt-clone

Another quick step. Since it’s Debian, just do

apt-get install apt-clone -y

on both boxes, and you’re set.

Copy the apt-clone package from vm-old to vm-new

apt-clone makes doing what we’re doing very simple. We’ll be using the clone command on vm-old, and restore on vm-new.

From vm-old, run:

apt-clone clone /tmp/ldap

This may seem to throw an error for you. Here’s what my output looks like:

root@vm-old:~# apt-clone clone /tmp/ldap
not installable:
version mismatch:Note that you can use --with-dpkg-repack to include those packges in the clone file.

Not to worry — this is fine. Take a look at the source of apt-clone for an explanation here. Just to verify, make sure /tmp/ldap.apt-clone-tar.gz exists:

root@ldap:~# ls /tmp/ldap.apt-clone.tar.gz
/tmp/ldap.apt-clone.tar.gz

Tab over to the sftp tab in tmux, and copy the package over to vm-new:

sftp> put /tmp/ldap.apt-clone.tar.gz
Uploading /tmp/ldap.apt-clone.tar.gz to /home/alec/ldap.apt-clone.tar.gz
/tmp/ldap.apt-clone.tar.gz                                                                                                                                           100%   43KB  43.0KB/s   00:00

On to the next step.

On vm-new, restore the packages using apt-clone

Tab over to the ssh tab in tmux, and let’s get the restore rockin:

root@debian:~# apt-clone restore /home/alec/ldap.apt-clone.tar.gz

This may take a while, so go make yourself a nice cup of coffee. Don’t forget to check back from time to time, as you’ll most likely get some prompts on which you need to provide input.

While the restore is rocking, copy over any necessary config files, databases, and ASCII art from vm-old to vm-new

I’m running OpenLDAP for my LDAP needs. I don’t want to re-create everything and annoy all 8 of my LDAP users, so I’m going to backup and restore the databases. Tyler over at Tyler’s Guides has a very nice article on this process, which I’ll be basing my approach on.

For more information, please checkout Tyler’s Guide. I’m only going to put the commands I used into this step, and he has a great explanation of what needs to be done and why.

root@ldap:/tmp/ldap_backup# slapcat -n 0 -l config.ldif
root@ldap:/tmp/ldap_backup# slapcat -n 1 -l data.ldif

Now it’s time to copy over our new LDAP backups, and any other config files from vm-old to vm-new. I’m doing this from my SFTP tab on the vm-old box

sftp> put /etc/ldap/ldap.conf
sftp> put /tmp/ldap_backup/config.ldif
sftp> put /tmp/ldap_backup/data.ldif
sftp> put /etc/network/interfaces
sftp> put /etc/iptables.rules
sftp> put /etc/msmtprc

Those are the biggies. I want the new VM to have the same network settings as the old VM, so I’m going to be lazy and just copy over the interfaces file from vm-old. I like to keep my firewall rules in /etc/iptables.rules, so I’m copying over that as well. msmtprc is the part that mows my lawn, cooks, folds laundry, so we have to make sure we keep that little bugger alive on the new VM as well.

Once the restore is complete, restore any databases, if necessary

I’m going to refer back to Tyler’s Guide here again, as the restore process for the LDAP backups is outlined quite well over there.

root@debian:~# service slapd stoproot@debian:~# ls -ld /etc/ldap/slapd.d/
drwxr-xr-x 3 openldap openldap 4096 Nov 26 21:34 /etc/ldap/slapd.d/root@debian:~# mv /etc/ldap/slapd.d /etc/ldap/slapd.d.`date '+%Y-%m-%d'`root@debian:~# slapadd -n 0 -F /etc/ldap/slapd.d /home/alec/config.ldif
root@debian:~# chown -R openldap:openldap /etc/ldap/slapd.droot@debian:~# ls -ld /var/lib/ldap
drwxr-xr-x 2 openldap openldap 4096 Nov 26 21:51 /var/lib/ldaproot@debian:~# mv /var/lib/ldap /var/lib/ldap`date '+%Y-%m-%d'`root@debian:~# slapadd -n 1 -F /etc/ldap/slapd.d -l /home/alec/data.ldif

For the non-LDAP pieces, I’ll just be moving them to the same locations in which they resided on vm-old.

root@debian:~# mv /etc/network/interfaces /etc/network/interfaces.original
root@debian:~# mv /home/alec/interfaces /etc/network
root@debian:~# mv /home/alec/msmtprc /etc
root@debian:~# mv /home/alec/ldap.conf /etc/ldap

I’m also going to update the hostname on vm-new to match the hostname on vm-old.

root@debian:~# vim /etc/hosts
root@debian:~# vim /etc/hostname

Last thing is to delete and re-create the SSH keys

root@debian:~# rm -rf /etc/ssh/ssh_host_*
root@debian:~# dpkg-reconfigure openssh-server

Power off vm-old, reboot vm-new, cross fingers

The big step. The moment of truth. All or nothing. Let’s do it!

Power off vm-old

root@ldap:~# shutdown -h now

Reboot vm-new

root@debian:~# shutdown -r now

Verify that everything is working as expected.

Conclusion

This is a pretty solid method of migrating any Debian system to a new machine. Since I need to move several VMs from my VirtualBox host to Hyper-V hosts, I used my setup as an example. I also covered a few extra bits relating to OpenLDAP as well. Hopefully you’ll find this helpful.

If you have a different setup, which required changing a few things, let me know how it goes!