Let’s suppose you are administering a GNU/Linux server where some complex tests and updates must be run on. Now, there are myriads of different ways – tools and techniques – that surely would allow you to do precisely that without affecting the real server – not to mention if you do have this particular server already virtualized -. And yet, for those who still run old fashioned servers on a real box, sometimes it could be of service to have a virtualized version of it. As an example: whilst updating the GNU libc6 library to defeat the GHOST vulnerability, as previously discussed here. This, even when you are still running a real box, will allow you to deploy updates and do delicate tasks on the virtualized one to ensure that, once applied to the real one, the system will not crash.
The discussion below will show how to achieve that using basic GNU/Linux tools and commands. No need to buy expensive or complex software packages, just a live GNU/Linux distro like RIP Linux and an open source virtual machine software like VirtualBox will do. It is important to remark that this technique does not try to equal the real one’s performance; this idea serves only one purpose: to allow a systems manager to test some delicate updates on the system without compromising the real one’s uptime. Therefore, the VirtualBox election will down the original server’s performance, of course, so please notice the virtualized server will not be a replacement for the real box.
Step 1: Prepare the virtualized hard disk
After creating a new virtual machine with , let’s say, Virtualbox, you need to accommodate its disk partitions. It would be ideal to partition the hard disk using the same partition table as in the original system, but this is not mandatory. So, let’s imagine our server has one hard disk called /dev/sda, thus:
sever:# sfdisk -d /dev/sda > /tmp/server-sda.sfdisk
Once we have the original table partition scheme, we have to boot our Virtual Machine with a live system, let’s say RIP Linux, set an IP address and ensure that we have connectivity to our real box. Then, we can get the dumped partition’s scheme file by using the secure shell this way:
vmachine:# scp server:/tmp/server-sda.sfdisk .
Finally, we must re-generate the same partition table on our virtualized hard disk and format the slash and swap partitions:
vmachine:# sfdisk /dev/sda < server-sda.sfdisk && ( mkfs.ext4 /dev/sda1 … ; mkswap /dev/sdaN … )
Step 2: Image the real system
Inside the virtual machine, we need to imagine the whole real system but the /home, /sys, /proc, /mnt, /media, and optionally /root directories. The best way to achieve that is by means of running the rsync command through the secure shell channel. First, we need to mount our destination file-system. In this particular case, let’s imagine our virtualized hard disk containing the whole slash partition will be /dev/sda1, so:
vmachine:#mount -t auto /dev/sda1 /mnt/sda1
Once we have mounted the partition, we need to imagine the real box on it:
vmachine:# rsync -avHz root@server:/ –exclude home –exclude sys –exclude proc –exclude mnt –exclude media –exclude root .
After that, we will have the entire system imaged on our virtualized hard disk.
Step 3: Adjust the boot loader
Once the entire system has been successfully imaged on our virtualized hard disk, we need to adjust the boot loader or it would not boot up correctly. Let’s assume our virtualized partition /dev/sda1 holds the entire /boot directory, and that according to step 1, we have already ensured that the partition table is exactly the same as in our real server. In this case, the /dev/sda1 partition would have the “boot” flag set. Now, let’s imagine we have the GRUB 2 Bootloader installed on our real box, so all we need to do is to re-install grub on the MBR. Before doing that, we need to create all the directories we have skipped from imaging on the previous step:
vmachine:# mkdir /proc ; mkdir /sys; mkdir /mnt; mkdir /home; mkdir /root; mkdir /media …
Then, we have to prepare the /proc, /sys and /dev directories accordingly. Due to the fact that the /proc and /sys directories are virtual memory representations, the best way to achieve that is by connecting the real ones – the ones running on the live system – to the virtualized directories. When it comes to the /dev directory, it must be done the same way because all the device files have already been created by the UDEV system on the live system, and it could differ from the real box. Thus:
vmachine:# mount -t none /dev /mnt/sda1/dev -o bind ; mount -t none /proc /mnt/sda1/proc -o bind ; mount -t none /dev /mnt/sda1/dev -o bind
Finally, we can re-install the GRUB bootloader by issuing a chroot command this way:
vmachine:# chroot /mnt/sda1 ; grub-install –recheck /dev/sda
After finishing the re-installation of the GRUB bootloader, we can reboot the virtual machine – making sure before that that our virtualized system will boot up from its hard disk instead of booting up from the live system -. After a while, we should have the real box now virtualized, ready to use.