Sunday, April 22, 2012

Migrate Encrypted OS to Another SSD Drive using VirtualBox

Finally, I got resolution on my encrypted drive migration problem using VirtualBox, and the best part is: it's done using only free, open source applications. In a nutshell, the steps are:

  1. Import system to a virtual machine by cloning it
  2. Decrypt virtual drive
  3. Extend virtual drive
  4. Copy virtual drive to a new physical SSD

WARNING: this is what I did, it worked for me, it might not work for you. If you blow your drive, or ANYTHING else negative happens, including, but not limited to rain, hail, earthquakes, FBI, do not come blaming me, I have nothing to do with it, all is completely your own responsibility.

Now that we are done with indemnification, here is what I did:

Make a raw copy of encrypted disk

I have temporarily created NTFS file system on a new disk, so that I could copy a raw image of encrypted disk into it.

I used Live CD to boot into Ubuntu and make a raw image of encrypted system disk. You could use disk utility to see which disk is mounted on what device. My encrypted disk has loaded as sda and target SSD loaded as sdc. I mounted NTFS partition , and created a raw copy of encrypted disk, by going into the terminal and executing following command:

# mount /dev/sdc1 /mnt
# dd bs=8M if=/dev/sda of=/mnt/original-disk.img 

Time used: ~1 hour.

Import drive into VirtualBox

I already had VirtualBox installed. Now I need to import a drive. Use following command to convert raw disk into a virtualbox disk:

> vboxmanage convertfromraw m:\original-disk.raw D:\Files\VM\Migrate\original.vmdk 

IMPORTANT!!! I will later on decrypt OS on this virtual disk, so it's important that drive D: is encrypted. Alternatively, if you don't have a second encrypted disk, you can just shred this file instead of delete, and/or clear the empty space. Needless to say, do not use non-encrypted SSD for this purpose.

Once this is over, I created a virtual machine and attached a system disk to it. I gave it maximum amount of processors and plenty of RAM, since it will be using CPUs to decrypt the system. Here's how it looks like:

It took me a lot of effort to ensure, that when I boot this image, I do not see this:

STOP 0x0000007B happens because by running OS in virtual environment, we are using different disk controller, than originally was on the system. Windows will crap out when there are no drivers pre-configured for new disk controller. This is very annoying, especially since it is perfectly capable of locating the drivers or using generic one, but it is what it is. I tried quite a few combinations, until I finally booted using this:

Time used: ~1 hour for conversion, many hours to figure out controller snafu.

Boot and Decrypt Source Disk

Now that my virtual machine is bootable, I could log on and decrypt the system drive. This operation will not expose sensitive data, since virtual disk image is located on encrypted drive.

As you see, takes awhile to decrypt. Unfortunately, VirtualBox is not too speedy. Good thing, you could use your computer while doing it. Lower down priority of virtualbox process, that would make computer more snappy.

Prepare a Copy of Target Disk

Open up target drive properties in Device Manager, and note how many megabytes exactly is on your target disk (Capacity):

I went to VirtualBox and created target disk with exactly that size:

Move Installation to New Drive Image

I added the new drive, this time using SATA controller, just so that Windows installs drivers for it, and verified that computer starts. I also added CDROM, so that I could start Ubuntu to copy drive.

I started the OS to make sure the drivers get installed. While working on that task, it becomes very clear how much of a speed boost was system on SSD.

Now I boot Ubuntu and copy disk to the new drive image. I am not moving it to SSD yet, because the image still needs to be encrypted

Then I reboot, and use gparted to expand the target disk:

Time to complete: a little over an hour.

Encrypt Target Drive

I am back to putting drive on IDE controller, somehow I'm getting BSOD otherwise

After chkdsk cycle, the OS will start, and I am going to encrypt it, business as usual, except it takes quite a bit of time:


Convert VDI to raw bytes

Theoretically, it is possible to mount a physical disk directly on virtual machine, however I had problems writing to it after that. It is also (theoretically) possible to clone VDI to \\.\PhysicalDriveX using VBoxManage, but that also didn't work well for me.

So I took a longer, but safer route - make a raw image of a target drive, then copy it in Ubuntu. For that, I used a spare drive. Since the image is already encrypted, I don't need another layer of encryption on the drive.

> VBoxManage clonehd D:\Files\VM\Migrate\Migrate.vdi I:\target.raw --format RAW

Copy Drive Image to SSD

For this task, I physically connected the target drive and the one that has an image, and booted my physical box Ubuntu.

unmount SSD (Ubuntu mounted all volumes automatically), and dd image to a device:

# umount /dev/sda1
# dd bs=8M if=target.raw of=/dev/sda

Time to complete: less than 1 hour. That did it, and now my new SSD is bootable.

Some observations

There is probably an easier way to migrate the data. One way is to grab image of system drive using disk2vhd utility, which will allow to skip decryption step. Comment with experiences and happy migrations!

1 comment:

  1. I loved your warning! No worries - with me also everything went ok. I used your hints while learning how to work with ideals data room . It is a cloud tool for business.