Lewis' Blog Tales from the trenches of information technology


Migrating a bare-metal Windows 2000 install to a VirtualBox guest

Download PDF

A client's sole remaining W2K box started having boot issues the other day. It had been on the slate for about a year (or two or three) for an upgrade, but somehow, it just kept chugging along, so we left it be. Well, after confirming that the drive hardware (80GB Western Digital SATA) was in good shape (I did this from a Parted Magic USB stick boot, running just some rudimentary SMART diagnostics), and yet still unable to get W2K to move beyond the first graphical screen during startup, we decided that the time had come for a change.

The issue, of course, was the sheer volume of cruft which had accumulated on the old install, migrated from NT 4 (no kidding; the volume creation date was 1999, when we were migrating clients to Windows 2000 prior to Y2K 1). It wasn't just the cruft, though: it was the collection of old software which he really does use on a regular basis. Some of this may be installable and functional under a more modern OS version, but there are no guarantees.

So, this seemed like a perfect candidate for a Windows 7 x64 host (he likes Windows, and I'm not about to have him switch over to Linux at this point) and a migration of the existing W2K volume to a VM under something. My hypervisor of choice is VirtualBox, simply because I'm more familiar with it than any of the other offerings around.

I pulled the drive, and went back to my office to spec out a new machine for him...and have a go at creating a vdi from the existing drive.

[My own host machine is running openSUSE 12.2 32-bit (presently; I'm going to change the architecture in this box shortly). Still, W2K fits nicely under a 4GB 32-bit host, so I didn't anticipate any problem on that front.]

Imaging the Drive

Creating an image of the drive was fairly straightforward. With the host machine shut down, I cabled the 80GB drive as the third SATA hard drive, powered back up, and then went into the BIOS to ensure that the drive ordering was correct (i.e., that the 80GB was listed last). After that, I booted normally.

Next, I opened a terminal and ensured that I had enough room on my Vbox partition (/Vbox) to hold an image of the drive (I knew it wasn't nearly full, but without wiping the free space, all of the fragmentation comes along for the ride). With that out of the way, I needed to determine the actual size of the physical disk, using fdisk -l:

# fdisk -l /dev/sdc

Disk /dev/sdc: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdf5ee900

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *          63   156296384    78148161    7  HPFS/NTFS/exFAT

From the above, the important thing I noted was the size in bytes (80026361856). I needed that for the actual imaging, which I accomplished with VBoxManage 2:

# cat /dev/sdc | VBoxManage convertfromraw stdin /mnt/Vbox/NT5SP4.vdi 80026361856

Notice that I didn't image the partition (sdc1), but rather the entire device (sdc).

This resulted in a 46GB NT5SP4.vdi.

At this point, not wanting to take any unnecessary chances with the physical drive, I shut down and disconnected it.

Creating the VM

I used the VirtualBox Manager (GUI) to create a Windows 2000 guest with 256MB RAM, AC'97 audio, and AMD NIC (via NAT; that will change later on). I then attached the NT5SP4.vdi to an IDE controller (that's really a misnomer, as IDE is a controller-less technology, AFAIK; it's really just an interface), and configured the host DVD to pass through to the guest, so I could mount up a W2K Pro SP4 slipstreamed disc (more on this in a moment).

Booting the VM for the First Time

The moment of truth had arrived. I started the new VM, and it did pretty much what the bare metal install did: booted up to the first graphical screen (the one with the Windows 2000 graphic on it and the moving bar), and stopped. Oh, well.

I inserted my home-grown W2K Pro SP4 slipstream CD into the DVD drive and rebooted the VM. At the prompt to press any key to boot from CD, I hit the spacebar, and let the installer start. I next selected the option to repair an existing installation, and finally, to repair from the recovery console. At the prompt, I selected the single installation for logon, and entered the Administrator password. So far, so good.

I then ran fixboot, to write a clean bootsector to the virtual drive, followed by a full chkdsk pass (I needed to add the /p to force a complete check), which corrected some minor errors.

Getting the Virtual Hardware Right

I knew that the hardware was sufficiently different from the bare metal machine that I would need to reenumerate it, so I rebooted to the CD again, this time selecting the option to install Windows. After accepting the license agreement, I got the list of existing installations, and the second repair option, which I selected.

The repair install went off without a hitch, though I should have thought to swap out the Novell locwin32.dll module under \WINNT\System32 when I was at the recovery console earlier (this system was - and will be - in a Novell environment, and the Novell Client for Windows replaces a few components with ones of its own which are somewhat incompatible with their Microsoft-supplied counterparts). This particular module causes some noise during the final stages of the repair install, but these errors may simply be clicked through to continue the process.

Once the installation completed, instead of allowing the VM to reboot and start the repaired installation, I swapped the Windows 2000 CD for my ERD Commander 2000 disc 3. I also shut the VM down and modified the configuration to add a floppy drive. I then created an image of a floppy disk using standard tools:

# mkfs.vfat -C "floppy.img" 1440

and mounted that, so that I could copy locwin32.dll from another W2K installation running the same version fo the Novell client:

# mkdir /mnt/floppy
# mount -o loop -t vfat floppy.img /mnt/floppy

I transferred the file via a SAMBA share from one of my remaining Citrix Metaframe 1.8 boxes (running Windows 2000 Advanced Server).

I then mounted the floppy image in VirtualBox, restarted the VM, and pressed F12 to select a boot device (so that it wouldn't try to boot from the floppy - remember those days?). I hit "c" to boot from CD, and let ERD Commander start. Once booted, I copied the module:

c:\> copy a:\locwin32.dll c:\WINNT\System32

I "ejected" the floppy from the VM and rebooted, ejecting the CD just before the guest started back up again.

Welcome Back

This time, the VM came all the way up. I was able to log in and had connectivity. I quickly reinstalled the last Novell client for Windows 2000, rebooted, upgraded IE to 6 SP1 (because 5.0 doesn't cut it for Windows Update!), and did some more housekeeping.

The problem was that I was getting nagged with a failure to load fltmgr.sys. This typically (in a bare metal environment) causes a bluescreen, and I was thankful that it did not in this instance. Additionally, in spite of my having the forethought to upgrade IE, it crashed when I tried to run Windows Update. Hmmm...

Update Rollup 1 for Windows 2000 SP4

I had to do some digging to refresh my memory on this one. Apparently, Microsoft changed soemthing in fltmgr.sys in the update rollup, and apps written to depend upon the updated module were sadly disappointed when they couldn't get anythign but the one which shipped with SP4. The solution was to manually download the update rollup and install it. This wasn't foolproof, either, as it seemed to cause some unintended side-effects, prompting me to uninstall it via safe mode (the symptom was that logon was slow - if at all - and network connectivity was affected - which was probably the cause of the logon issue, even though logon was local).

After uninstalling the rollup package and rebooting normally, I noticed that the fltmgr.sys error was mysteriously gone (registry setting?). Windows Update failed to install BITS 2.0 (specifically, Windows2000-KB842773-x86-ENU.EXE, which is luckily available for direct download from Microsoft, linked from this KB article.

After installing Windows2000-KB842773-x86-ENU.EXE, the system prompted for a reboot. When it came back up, I was able to run Windows Update normally and apply all of the available updates 4.

Next up: transferring the new VM to its final host.

  1. At the time, we didn't really think that NT 4 was fully Y2K-compliant.
  2. Some of this comes from the VirtualBox wiki, but incorporates my prior experience with moving W2K installations from one system to another.
  3. ERD Commander was a more fully functional commandline environment for W2K than the recovery console; I could have used a Bart PE disk - based on XP - , as well, but this was sufficient for the task. ERD Commander was available from Winternals, which was gobbled up by Microsoft when they hired Mark Russinovich.
  4. One of the downsides - or not, depending upon the reason for the repair install - of the repair install procedure is that whatever updates were on the machine before the repair are overwritten by whatever is on the installation medium.
Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.