As described in another post, I was transitioning to a Linux system. As part of that system, I wanted to run Windows in a virtual machine (VM) in VirtualBox. I already had some Windows installations, backups, and CDs. I wondered which one(s) I could and should run in that VM, and which one(s) I might want to run in other VMs at some point.
- Start from Scratch
- Preconfigured VM
- Convert a Backup Image
- Virtualize a Physical Windows Installation
- Restore an Image into an Empty VM
- Raw Hard Disk Access
- Converting a Simple Windows XP Physical Installation
- Converting Various Windows XP Backup Images (.tib)
- Direct Virtual Installation
- A Minimal Windows 7 Ultimate x64 Upgrade VM from Scratch
- Converting a Large Windows 7 TIB to VHD to VirtualBox VM
- The Essential Windows 7 x64 VM
There were several possibilities:
- Start from Scratch. I could install Windows from scratch inside the VM. I had recently done this with a copy of Windows XP, for purposes of virtualizing various Windows programs. Setting up new Windows installations would be relatively easy in that sort of case, where the goal was to create the simplest possible installation. But I did not want to have to recreate, from scratch, a heavily tweaked Windows 7 installation of 50GB or more.
- Preconfigured VM. I could download and run a preconfigured Windows VM from Microsoft. But since those VMs expired after just a few months, that approach did not seem ideal for my goal of setting up VMs that I could use long-term.
- Convert a Backup Image. I could try to convert a backup image of a physical Windows installation to a VM. My images were mostly .tib files made with Acronis True Image Home 2011. (My version of Acronis included the Plus Pack. But it didn’t seem to have the Recover feature that eHow found in Acronis Backup & Recovery, or that reportedly existed in the latest version of Acronis True Image.) I had previously downloaded VMware’s vCenter Converter Standalone — oddly named, if “standalone” sounds like it should mean portable: I had to install it. I did that, and also downloaded their User’s Guide. Sadly, the User’s Guide contained no references to Acronis. VMware Workstation was apparently able to convert .tib files, but I wasn’t too eager to buy a copy of Workstation ($250). Otherwise, it sounded like VMware’s vCenter Converter version 6 would only work with physical installations, VMware VMs, and Microsoft Hyper-V Servers. This was apparently a change: older versions of vCenter Converter (evidently no longer available except through questionable third parties) supposedly supported Acronis .tib files.
- Virtualize a Physical Windows Installation. I could start with an existing physical Windows installation, or could create one by restoring an Acronis .tib file onto a willing computer, and could then virtualize that installation into a VM file that VirtualBox would recognize. To achieve that virtualization, I could use vCenter Converter (above), or I also reportedly had the option of using Disk2VHD to create a VHD file (maximum size apparently = 127GB), which was then convertible into .vmdk format, which VirtualBox would recognize.
- Restore an Image into an Empty VM. I could use Acronis to restore a .tib image into an empty VM. Acronis said this would entail booting my version of True Image from an Acronis live CD inside the VM, but advised that this approach was less reliable than converting a .tib into a VM. It sounded like the reliability problem had to do with recognition of drivers inside the VM.
- Raw Hard Disk Access. There was a raw hard disk access technique, where the Windows installation on a hard disk would not be virtualized, but would rather be accessed directly from a VM in which no separate OS was installed. So, for example, in a dual-boot system, I might not need a separate Windows VM to run in Linux; I might instead create an empty VM and link it to the underlying Windows dual-boot installation. There seemed to be various advantages and risks: performance might improve, but the entire contents of the drive containing the Windows installation might be at risk. I decided not to pursue this option at present.
That information narrowed down the choices among paths going forward. First, it would make sense to set up one basic Windows installation for each version of Windows that I might want to use in a VM. It was possible to change the product key in a Windows installation, so there would be no reason to create multiple Windows 7 x64 installations, for example, if the user had multiple Windows 7 x64 installation DVDs lying around. The more sensible thing would be to create just one 64-bit Windows 7 VM, and then change the key in copies of that VM later, as needed.
It seemed that those and other physical installations would probably be best virtualized by using VMware vCenter Converter 6. Reputation and my own experience suggested that a VM produced by that tool would probably work well, and it appeared that VirtualBox would be able to use it. It was not yet clear to me whether this sort of virtualized installation would produce hardware compatibility or activation issues when run in a VM whose “hardware” differed from that of the machine where it was originally installed.
Then there was the question of what to do with Windows installations that now existed only in Acronis .tib backups. Restoring directly to a VM didn’t sound like the recommended approach. The choice seemed to be, either restore them to physical machines and then convert them to VMs as above, or look further for a way to convert the .tib files into VMs.
At this point, some additional possibilities came into view. I might not buy a new copy of VMware Workstation or Acronis True Image just for this purpose — especially True Image, whose reputation had deteriorated considerably over the years. But I supposed it couldn’t hurt to use apparent offers to download and use Acronis or VMware software for a 30-day trial. Also, I belatedly recalled that I did have an old copy of VMware Workstation, purchased in 2008; perhaps it would work to virtualize some of these installations. Finally, and perhaps most important, it turned out I was wrong about my Acronis software: it did have a conversion tool; I had just never used it before, and had not looked in the right place.
Approaches Tried with Windows XP
Converting a Simple Windows XP Physical Installation. I had a basic Windows XP physical installation — that is, just the operating system (OS), with virtually no other software installed — on an old 32-bit Dell laptop. The steps I took with this installation were as follows:
- I installed vCenter Converter 6. WinXP was able to run that program. A search led to the vCenter User’s Guide (p. 44), which said I should turn off the firewall, UAC, and antivirus; disable simple file sharing; and remove old VMware Converter software. But it didn’t say tell me which kind of output to prefer. There were newer and older choices for VMware Workstation, Fusion, and Player. Fusion was for Mac. Workstation was expensive. Like MakeUseOf, I chose Player 7. Now vCenter said it was planning to copy all of that Dell computer’s drives. I had to click on that, so that it would convert only the Windows program drive, and would save it in the Minimum size. I didn’t change any other default values. The vCenter Converter took about nine minutes, on this 4.3GB WinXP installation, and produced a 2.1GB folder containing a .vmdk and an accompanying .vmx file.
- I could have converted the VMDK to VirtualBox .vdi format, but didn’t bother; it was possible I would want to use it in VMware Player sometime. To try it out, I made a copy and opened it, on my main machine, with VirtualBox > Machine > New > Expert Mode > fill out the details (using the name that I had given the .vmdk) > Use an existing virtual hard disk file > navigate to the newly create VMDK > use settings discussed in a previous post. When I clicked Start, the VM ran. Almost immediately, I got a Windows Product Activation notice indicating that Windows XP would have to be reactivated within 3 days because “the hardware on the computer has changed significantly.” I said no: if I was going to keep and activate this VM, I would first want to make sure it had the right product key. We proceeded to another error: “Adapter Problem: A wireless physical adapter is not installed.” But Internet Explorer was able to go online. I went into Control Panel > System > Hardware tab > Device Manager. There were two yellow question marks: not for the networking hardware, but rather for Base System Device and Video Controller (VGA Compatible). The Found New Hardware Wizard had come up, so I told it to do its thing. But it was unsuccessful. I tried Windows Movie Maker. It ran. It looked like there were some issues to sort out, but basically the conversion had worked: the simple XP physical installation was operational in a VirtualBox VM.
Converting Various Windows XP Backup Images (.tib). I had several Acronis TIB images of old Windows XP installations, going back four to seven years. These required some tinkering. I proceeded as follows:
- I tried using the Acronis conversion tool with each of those TIBs. It was willing to produce only .vhd format output. For the first TIB I tried, the process terminated with an error: “Failed to create the scheduled task. Error #1722 – ‘The RPC server is unavailable (0xFFF0)’.” The option for More Details provided Event Code 0x00640068. The Acronis Smart Error Reporting page was willing to look up such Event Codes only for newer versions of True Image, so I pretended I had one of those — but it reported having no information on that code. A search led to a suggestion to go, in Windows 7, to Start > Run > services.msc > Acronis Scheduler2 Service > right-click > Properties > General tab> Startup type: Automatic > Log On tab > Local System account. Then, back in Services, right-click again and choose Start. This time, the Acronis conversion tool did not produce an error; it just seemed to die. After a few moments, it produced a VHD file of only 33KB. I wondered if perhaps this meant that that particular TIB was dead. I tried another TIB. It produced an error: Unsupported File: Error while opening the archive file. The archive format is not supported by this operation.” OK, there was really something wrong with that TIB. Another: VHD produced — and now I saw that this VHD, and also the one I thought was only 33KB, had grown dramatically, to at least three times the size of the TIBs from which they came.
- It turned out that VirtualBox would recognize VHDs directly, without intermediate conversion. When I tried running the first one in VirtualBox, it stopped with “GRUB loading, please wait … Error 21.” From a search, I got advice to boot with the Windows XP CD and run fixmbr. To boot the CD, I was advised to put the CD into the CD drive, power off and restart the VM, hit F12 (alternately, Host-P, where Host was, by default, the right Ctrl key, as indicated in the lower right corner of the VM), and indicate that I wanted to boot from the CD-ROM. When the CD started up, I had to “Press any key to boot from CD,” and then, when I got to the Welcome to Setup screen, hit R to repair XP using the Recovery Console. Unfortunately, this stalled early: I got “FATAL: Could not read from the boot medium!” It seemed I first needed to go into VirtualBox > Settings > Storage > click on the Empty CD icon > click on the other CD icon at the right and choose the correct CD. Apparently that would tell F12 which CD I was referring to. So now I did get to the Recovery Console. It asked for the Administrator password. Jeez, from eight years ago? Who remembers? I hoped it was a blank, and just hit Enter. That worked. If it hadn’t, I would have had to use a password reset tool. Now, at the C:\WINDOWS prompt, I typed “fixmbr” and then “fixboot.” Then I typed “exit,” and didn’t hit a key to restart the CD, and this time the VHD ran.
- I got the Windows Product Activation notice again. I passed that and got a message, “Your display driver has changed,” giving me the option to reinstall the driver. I went with that. For some reason, the mouse wasn’t working in the VM: I could select the frame around the VM, so that my keystrokes would apply inside rather than outside the VM; but to accomplish anything inside the VM, I had to use Tab and Alt-Tab and Enter keys. Next, it wanted to reboot to finish installing that driver, but without the mouse, I couldn’t make that happen. This was just as well, because then I saw that WinXP was slowly detecting other hardware. The Found New Hardware Wizard was no more effective than before. Eventually I got a message allowing me to reboot the VM, and I was able to make that happen via keyboard.
- Now the mouse was working. I had to wait for XP to go through a slow bootup process, with all the accessories I had apparently installed in this old system. I went into Control Panel > System > Hardware tab > Device Manager and saw yellow question marks for the same two items as in the other WinXP VM (above). This time, I decided to troubleshoot those issues. A search for the first one led to an indication that this problem would be resolved if I installed the VirtualBox Guest Additions. In the VirtualBox menu on the top bar of the VM, I went to Devices > Insert Guest Additions CD Image. Then I rebooted the VM. Machine > Settings > Storage indicated that VBoxGuestAdditions.iso was installed, but Device Manager still saw a problem.
- Possibly the problem was that the VM was unable to go online. Windows XP networking was a nightmare in the best of times, and I was completely rusty on it now. A search led to a variety of experiments. Eventually I discovered that the old system had used ZoneAlarm, which was fine, but possibly it was the reason for the seemingly blocked network access. I disabled all its settings, but that did not seem to solve the problem. Eventually I uninstalled it, reasoning that it may have been valuable on a standalone PC, but I would use install antivirus software as needed within the VM. That got me started on uninstalling old printer software as well. I saw that I also had Acer eDisplay and EVGA Display Driver software installed; the VM already had a video driver; perhaps these programs were the cause of the recurrent yellow mark in Device Manager, regarding the display; so I uninstalled them too. There was a driver for an AMD CPU, which surely wasn’t relevant here; possibly it was the cause of the VM’s extremely slow startups so far; so out it went! Basically, I removed all programs related to hardware. There didn’t seem to be any installed programs specifically related to networking, so rogue software didn’t seem to be the solution to the inability to go online. I would have tried downloading and installing PRO2K3XP_32.exe in the VM per one user‘s positive experience. But I began to realize, a bit belatedly, that this VM didn’t have any software I found particularly interesting. So I gave up on this machine.
Direct Virtual Installation. As noted above, I had already used the Windows XP installation CD to create a VM in VirtualBox. This was a very minimal installation, never connected to the Internet and thus lacking any potential for interruptions from viruses or from antivirus software, for purposes of virtualizing applications.
Approaches Tried with Windows 7
Based on the foregoing experiences with Windows XP and my larger goals, it appeared that I would need three Windows 7 VMs:
- The minimal 32-bit Windows XP VM had done well, for purposes of virtualizing Windows programs. Nonetheless, I anticipated that some 64-bit programs would require, or would perform better in, a 64-bit virtualization environment. Thus, I expected to need a minimal Windows 7 VM. A copy of this machine could also serve as the starting point for a free upgrade to Windows 10, so that I would have a Windows 10 VM as well. Once these virtualization and upgrading activities were completed, I expected that this minimal machine would rarely be used.
- I had a 60GB Acronis TIB image of a full Windows 7 installation. As with the old Windows XP installations (above), I would hope that Acronis would convert this TIB to an undoubtedly large VHD file, and that this file would run in VirtualBox. Having decided to reduce my reliance on Microsoft, I would hope not to use this machine often. I did not expect it to perform well in a VM. Even with virtually no programs installed, I had seen how the installation of Windows Updates, by itself, could slow a machine. But this full installation was already set up to handle many tasks, and during the transition it could be valuable.
- The most important Windows 7 VM would be the one that I would view as my long-term assistant. This one would start as another copy of the minimal Win7 machine, but I would use it to run Windows programs capable of doing things for which Linux offered no realistic alternative.
The following paragraphs develop those three alternatives.
A Minimal Windows 7 Ultimate x64 Upgrade VM from Scratch. With guidance from the previous post cited above, and from an earlier post on installing with this particular Win7 DVD, I set out to create a Windows 7 VM that would have no updates, no antivirus, nothing else running, if possible, beyond the Win7 system straight out of the box (that is, installed directly from the DVD). As I started into this project, though, I saw that I had grown accustomed to a number of tweaks that made Windows 7 more useful and familiar for me. I decided to use tools and adjustments that I had found to be safe, during years of use, and that would not require additional applications. I made exceptions for a few applications that were portable or that I could shut down easily when necessary. Altogether, the steps I took were as follows (note also the instructions for making clean installations using an upgrade CD):
- Installation. I created the VM, using the same settings as before, including no network connection. (Note that access to 64-bit options required enabling Intel Virtualization, or its AMD equivalent, in the BIOS.) I used ImgBurn to create an ISO of the Win7 x64 DVD, started the VM, and got a “Select start-up disk” dialog. There, I navigated to the ISO and clicked Start. This started the Win7 installation process. I went with the defaults, chose Custom rather than Upgrade, clicked Next without entering a product key, and chose Ask Me Later for updates. Windows then finished installing itself.
- Guest Additions. I went into the VirtualBox menu at the top of the Win7 VM and chose Devices > Insert Guest Additions CD image > in the AutoPlay dialog, allow that program to run. That opened a Guest Additions Setup Wizard. I went with the default values and chose “Always trust software from Oracle Corporation” > reboot when offered the chance.
- Drive and Folder Rearrangement. I wanted to change the drive letter for the Guest Additions CD to be drive Y, which was the letter for the CD drive on my underlying desktop Windows 7 installation. But I decided this might confuse the Guest Additions. I did create a C:\Workspace folder, which I planned to use as the one-stop replacement for Downloads, My Documents, and other preassigned Windows 7 folders. (That redirection would be achieved through the .reg file, below.)
- Registry Edits. At this point, I began experimenting with the Win7RegEdit-x64.reg file discussed below. This file straddled the line between useful convenience and risky experimentation.
- Classic Shell. I had downloaded and installed Classic Shell on the underlying machine, and saved its settings as an XML file. Through the shared folder that I had assigned in the VM’s Settings, I could bring programs into the VM from the underlying Win7 desktop. Thus, I brought in and installed the Classic Shell program in the VM, ran it from the Start Menu, selected only its Classic Start Menu option, and chose its Backup button > Load from XML file. This enabled me to arrange the Start Menu in my preferred style.
- Device Manager. I went into Control Panel > Device Manager and verified that there were no hardware problems.
- Control Panel Tweaks. I got a notice from the Action Center. I went into there (Control Panel > System and Security > Action Center) and clicked the appropriate links to turn off messages about virus protection and Windows Update. I right-clicked Control Panel’s taskbar icon and chose “Pin this program to taskbar.” I also made these other changes in Control Panel: AutoPlay > uncheck “Use AutoPlay for all media and devices” > configure individually as desired (mostly “Take no action” except for media best handled via Windows Media Player); Display > Adjust resolution > as desired (e.g., 1280 x 960); Personalization > select a theme > Screen saver > None; Mouse > Pointer options > Show location of pointer when I press the CTRL key; Programs and Features > Turn Windows features on or off > disable Games, Tablet PC Components, Windows Gadget Platform, and Windows Search. That called for a reboot. There would be more things to set in a regular installation, as discussed in those (1 2) previous posts, but some of them would be premature in this minimal installation. I activated this VM in Control Panel > System > Windows activation (at the bottom).
- Drive and Folder Properties. In Windows Explorer, I right-clicked on Local Disk C > Properties > General tab: I named the drive “PROGRAMS” and unchecked “Allow files on this drive to have contents indexed.” Tools tab: Error-checking > Check now > Start > Schedule disk check. Then OK > Apply changes to drive, subfolders, and files > Continue > Ignore all. Also, on the desktop, I right-clicked the Recycle Bin > Properties > uncheck “Display delete confirmation dialog.”
- Set Defragmentation. Start > Run > dfrgui.exe. Even if the VM was located on an SSD, the scheduled defragmentation would only be affecting a virtual device, so presumably it would be OK to allow it to run on the default weekly basis.
Win7RegEdit-x64.reg. Before using this file, I brought in and ran the portable Ultimate Windows Tweaker (UWT) to change some usability settings (including the “Take Ownership” option). For reference, I opened up a parallel session of UWT on the underlying machine, so that I could see what I had clicked there — but I tried to keep in mind that the VM might have different needs than a desktop system. I had to click Apply at each UWT screen separately. Once this was done, I could delete UWT; its changes were already made in the system. Next, I brought in and ran the reduced version of my Win7RegEdit-x64.reg registry edit file that I had created for VMs, and then rebooted the VM. That .reg file contained some tweaks that were new to this particular installation. I rebooted after running it. (Later, I would find that this file also worked on a Windows 7 x32 installation.)
For final housecleaning, I hit Win-R > “sfc /scannow.” Next, Win-R > cleanmgr. Then I ran WinDirStat Portable on the VM’s drive C, to see if there were any obvious space hogs. The winsxs folder was a usual culprit, as was pagefile.sys, but there was not much I could do about either of those. Beyond that, I saw nothing obvious. I shut down the VM and looked at its files in Windows Explorer on the underlying Windows 7 system. This minimal Windows 7 x64 VM was about 8.9GB.
Converting a Large Windows 7 TIB to VHD to VirtualBox VM. As noted above, I had Windows XP backup drive images in .tib format created by Acronis True Image Home 2011. I also had a .tib image of a full Windows 7 system, with many programs installed. Now, using the Acronis tool, I converted that 61GB .tib into a 118GB VHD file. Then, as with the WinXP VHDs (above), I created a new VM using VirtualBox > Machine > New > Expert Mode > Use an existing hard disk file > select the 118GB VHD. Then I went into VirtualBox > Machine > Settings > use my standard settings.
Then I clicked Start. The VM took about two minutes to load. It probably didn’t help that my standard settings included only two CPU cores and 1GB RAM, though the latter was born of experience in which a VirtualBox VM with 2GB RAM, running in Windows 7, had ceased to function. An unexpected problem at the outset: the VM had been set to require Ctrl-Alt-Del to log in — but that key combination was intercepted by the underlying machine. To get past this, a search told me to use Right-Ctrl-Del. Windows said that it needed to reboot in order to apply certain changes. I was thinking, Not yet, so I said no. That was probably a mistake; it led into limbo. I powered down and back up. I got a message: “The application is not responding.” I decided to ignore that and wait. Eventually the VM began to pull itself together. But it was plainly running very slowly. I went off and did something else. When I came back hours later, there was a memory error. Somehow, it seemed to have messed up the system: I had to use the power button on the computer to start over. When I powered up the VM again, it ran CHKDSK automatically. CHKDSK detected and fixed a number of problems. But the VM still did not start.
I killed that VM, deleted the apparently corrupt VHD, made a new one, put it onto a solid state drive (SSD) in an external USB 3.0 dock, rebooted into Linux, started VirtualBox, and set up a new VM for the VHD there. My Linux installation was very bare-bones, so I tried allocating 8GB RAM (out of 16GB available) and three (out of four available) CPU cores. The VM started up fairly quickly. I shut it down and installed the Guest Additions. I downloaded the Extension Pack for the version of VirtualBox I was running — actually, instaed of downloading, I allowed VirtualBox (the default) to open it. I went back into VirtualBox > Settings > USB and saw that USB 3.0 was already selected. Now Windows 7 in the VM started up at what appeared to be about the same speed as the native Windows 7 installation on this desktop computer. Unfortunately, now I could see that this VM had problems. It would not even open Windows Explorer. It did open Device Manager, and there I could see several items had problems. I was not inclined to fix this thing. I bailed out of Linux, deleted the 118GB VHD, and returned to the native Windows 7 system.
From this exercise, I concluded that VirtualBox could run a large Windows installation at a decent speed. It would help if the underlying operating system was uncluttered. My new Linux desktop was an example, but possibly a simple Win7 system would have run it just as well. I guessed that some of the problems encountered in this VHD were due to peculiarities of that particular installation.
The Essential Windows 7 x64 VM. This final option started with a minimal Win7 VM (above) and added certain programs and adjustments. While I expected to have occasional uses for other VMs descibed above — for virtualizing applications, among other things — this fleshed-out Windows 7 VM would be the one that I would expect to run in my new Linux system for the foreseeable future. I expected that development of this VM would involve a number of steps, and therefore decided to elaborate upon that development in a separate post.