Monthly Archives: March 2017

Convert a physical server to a virtual one


I needed to “convert” a physical server to a virtual one, in this case I couldn’t and didn’t want to make the same disk partitioning size, but if that’s your case  you can still read. To be more specific, by convert I mean, not to reinstall every services on a brand new virtual machine but simply run what’s on the physical machine. Two reasons, my laziness and most importantly the fact that I’m not sure what was running on. Here goes one solution to do it, we’ll follow these steps:

  • full backup of the physical server
  • prepare the new virtual server on VirtualBox or what you prefer (KVM, etc …)
  • import the backup inside our virtual server’s drive
  • chroot using sytemrescue to update the MBR
  • boot our virtual server
  • Adapt some configuration

Backup !

First things first, do a full backup of your physical server, you can do it that way (adapt it to your use case):

tar -zcvpf mybackup.tar.gz --exclude=/archive --exclude=/mnt --exclude=/proc --exclude=/lost+found --exclude=/dev --exclude=/sys --exclude=/tmp /
Full backup of your server

Be careful with the owners and rights of your files !

Keep that backup somewhere close, we’ll reimport it later.

Virtual Server’s configuration

I’ll only explain how to do it on VirtualBox, if you don’t have it running yet, install it and start it.

Create your new virtual server by clicking on “New”, set your name, your OS type and the version. Just set the parameters as you wish, it depends on your physical server on what you want. Though, once you reach the configuration for the disk, choose vdi and make it a fixed size, it’s quite important for later.

Now your virtual server’s “hardware” configuration is almost done, just set some other settings to your convenience such as the network, boot order (for our test it’s best to select CD first) etc …

We’ll need systemrescue, so download it. Once you have the iso, select it in VirtualBox for your virtual server to boot on. Start it !

This step is about partitioning, so be sure of what you want and what you do. You can simply recreate the same partitions you have on your physical server or just set new ones, just be sure to put enough space for your data to fit in.

qemu-utils and our data

To reimport our data inside the vdi disk we have in VirtualBox we’ll use a cool tool inside qemu-utils. Poweroff your virtual server, it’s very important to not ruin your vdi. Let’s install it and see what we can do with it:

aptitude install qemu-utils
modprod nbd
Install qemu-utils

We need to activate the kernel module nbd too.

Now we’ll link a device /dev/nbd0 to our vdi disk:

qemu-nbd -c /dev/nbd0 <path to your vdi disk>.vdi
Link vdi disk to /dev/nbd0

Create mountpoint directories and mount your partitions:

mount /dev/nbd0p1 /mnt/vs1/boot/
mount /dev/nbd0p3 /mnt/vs1/root/
Mount your partitions

You can now rsync your backup data inside your partitions !

Once your done let’s clean up:

umount /mnt/vs1/root
umount /mnt/vs1/boot
qemu-nbd -d /dev/nbd0
Clean up

Chroot time

Our data is now inside our vdi disk, great, but we can’t boot directly because our MBR doesn’t exist. We need to fix that. Reboot your virtual server on systemrescue. Once you have the prompt you’ll chroot:

mkdir -p /mnt/root/boot
mount /dev/sda3 /mnt/root
mount /dev/sda1 /mnt/root/boot
mkdir /mnt/root/{sys,proc,dev,run,tmp}
mount --bind /proc /mnt/root/proc
mount --bind /sys /mnt/root/sys
mount --bind /dev /mnt/root/dev
mount --bind /run /mnt/root/run
mount --bind /tmp /mnt/root/tmp
chroot /mnt/root /bin/bash

If everything went well, you should be “inside” your physical server (as if), check a few files you know to be sure it’s well chrooted (/etc/hosts, content of /home, etc ..) if it’s alright, we can now update the MBR:

grub-install /dev/sda
update the MBR

If the commands didn’t yell at you, it’s looking pretty good, you can now poweroff your virtual server. Remove the systemrescue iso and boot your virtual server on its vdi disk, it should work 🙂

Adapt your configurations

A few examples about problems I ran into:

  • careful with your /etc/fstab if you used UUID, you’ll have to change your fstab with a chroot
  • if you didn’t keep the correct owners and rights of your data, it’s possible the virtual server will boot and couldn’t access the data, it will probably try to use a wrong user because of the suid
  • probably a part of your network configuration won’t work, or worse your access to the virtual server, you can clean your firewall with a chroot and then set a NAT rule in VirtualBox to access the machine. In my case, since I had only SSH to my physical server, the keyboard layout was US, and since I have an azerty keyboard it was a pain in the ass. I couldn’t edit easily any file. I decided to SSH on the virtual machine using a NAT rule and to install later the correct layout.