Windows 7: Native Virtual Hard Disk (VHD) Boot

I was interested in making Windows 7 Ultimate run faster.  One possibility that came to my attention was using native virtual hard disk (VHD) boot in connection with RAID0.  This post discusses that.

A virtual hard disk was just a hard disk in virtual form.  Normally hard disks were physical.  A virtual hard disk, like a virtual machine (VM), would exist as a file (or a set of files) on a physical hard drive, not as a physical device in itself.  In other words, the user would have a physical hard drive in his/her computer, and somewhere on that drive s/he would have a VHD.

The "native" part of "native VHD boot" meant that the user would have direct access to the VHD.  Ordinary VM software (e.g., VMware, VirtualBox, Virtual PC) would require the user to install an operating system (e.g., Windows 7, Ubuntu) to serve as host (also called "parent").  Then the user would have to install the VM software (e.g., VMware) to manage the guest, and then install another operating system (e.g., Windows XP) inside the VM software as guest.

The VHD concept seemed to be that the host layer would be removed from the equation.  There would be a virtual hard drive that could be loaded or unloaded, perhaps without rebooting the computer.  The computer would be running the "guest" machine (e.g., a Windows XP installation) in virtual form.  For example, a packaged Windows XP installation could run on computer A, or on computer B, without having to be reinstalled and without having to install a host and a VM program like VMware.  In addition to simplicity, this scheme would presumably have the advantage of improving performance by removing extra layers and tasks.

In Windows 7, native VHD boot was apparently available only in the Ultimate and Enterprise versions.  This meant that it could be out of the reach of ordinary users who were not inclined to spring for such expensive software, unless perhaps they had access to it through their jobs or through academic versions.  It did not appear that Ubuntu, for one, would be developing a comparable capability in the near future.  There were hypervisors like VMware's ESXi that apparently provided somewhat similar bare-metal functionality, but ESXi seemed unavailable for my purposes.

I was interested in the possibility of using native VHD boot with RAID0.  This interest arose from a desire to make Windows 7 and other operating systems run quickly.  New installations of operating systems would typically perform well, I found, but then time and the addition of more programs and other demands would slow them down.  So, for example, I had found that Windows XP running as a VM inside VMware Workstation on an Ubuntu host was much more stable than native WinXP, but its performance had slowed dramatically.  My attempts to fix it (even through reinstalling both Ubuntu and VMware) had failed.  After several years of experimentation, I had therefore recently given up on Ubuntu for my purposes.

VHD seemed to offer a good way to run Windows 7 in a RAID array.  I had found that Win7 did not, itself, support booting from the software RAID0 arrays that Win7 was capable of creating.  In other words, a Win7 user could use Win7 to create RAID0 arrays, and could speed things up somewhat by putting some programs and data files on such arrays; but the user could not boot Win7 from a Win7 software RAID0 array, and would therefore have to install and run some Win7 program files from a basic hard drive.

As an alternative, the user could create a RAID array using hardware, either on the motherboard or on a third-party controller.  Hardware RAID had potential advantages of performance, bootability, level support (i.e., the ability to choose versions other than RAID0 and RAID1, including some I had not previously heard of), multiple operating system access (i.e., the data would remain available regardless of how the machine is booted), and reliability.  The performance story was a bit controversial.  I had seen indications that motherboard RAID was no faster than software RAID, and I had heard some claim that RAID0 was no faster than non-RAID, but my own experience (in Ubuntu) was consistent with tests indicating that even a software RAID0 was markedly faster than non-RAID.  Cost was a consideration.  While RAID5 was perhaps ideal, a Newegg search for a SATA RAID5-capable controller would cost hundreds of dollars.  Removing the RAID5 constraint led me to a $30 Rosewill item.  I didn't need that myself; I had motherboard RAID 0, 1, and 10.  For reasons of cost, noise, and heat, I wasn't going to be installing four drives to have RAID 10 (a/k/a RAID 1+0, which Wikipedia (apparently backwardly) called a stripe of mirrors, as distinguished from RAID 0+1, a mirror of stripes).  So for my purposes, it was a choice between hardware RAID0 or software RAID0; and since I was now using Win7 rather than Ubuntu, the desire to boot in RAID0 meant I would be using motherboard RAID -- unless VHD gave me a good alternative.

At this point, I had a general sense of what VHD sounded like.  Among other things, it sounded great.  But it seemed that I wouldn't run into the actual drawbacks and impossibilities until I created my own VHD and tried to use it.  As described in another post, the first step in doing so was just to create and play around a bit with a VHD, within a regular, running Win7 system.

Windows 7: Introduction to Virtual Hard Disks (VHDs)

As described in another post in this blog, I was trying to figure out the best way to install Windows 7 Ultimate.  I had discovered native virtual hard disk (VHD) booting.  It sounded like I could use a native VHD to boot Win7.  I wasn't sure precisely how that worked, so I decided to give it a whirl.  This post describes that process.

I started with Win7 already installed and booted from a basic hard drive.  I had a two-drive software RAID0 array created by Win7.  Actually, it was a set of several RAID0 arrays, of which one was left empty and unformatted.  This, I hoped, would be the virtual partition on which I would install a bootable version of Windows 7.  I had not been successful in doing so natively (i.e., directly, without intermediary software).  I hoped to do so with a native VHD -- that is, a virtual drive that would create a Win7-boot-friendly world within the Win7 RAID0 partition.

The first step was to run Disk Management (Start > type "diskmgmt.msc").  (There were also command-line options.)  I could see my eagerly waiting empty RAID0 partition.  On the menu, I went into Action > Create VHD > Browse.  To my surprise, Disk Management seemed willing to create the VHD just anywhere.  It made sense -- the VHD was going to be contained in a single file that would function like other files -- but I had expected something like a partitioning program here.

I designated a location and filename:  D:\Current\Win7VHD.vhd.  Having heard nasty things about the dynamically expanding option, I went with the fixed size default setting.  Since I had the general idea that I was going to be installing Win7 inside this file, it seemed this file would have to be monstrously large, raising a question of backup:  would a single change anywhere in this file require another mega-backup?  A search led to a thread advising an allocation of 60GB to 100GB for a Win7 partition.  Informed posts in another thread echoed that; likewise a third.  I could spare 100GB on my existing setup without moving partitions, so I set it at 90GB (i.e., 92160MB) just in case there was some funky slippage that nobody was telling me about.  Win7 informed me that it was installing VHD device driver software.

I checked D:\Current.  There it sat, Win7VHD.vhd, size = 94,371,841KB = 92160MB.  Now what?  Apparently one option was to just treat this VHD like a data drive.  In Disk Management, I went into the Action menu pick, with the idea of clicking on the Attach VHD option.  But it was grayed out.  Apparently I was missing something there.  I figured the myster would be resolved eventually.  And then, right before my very eyes, Disk Management changed.  Now it was displaying a new, 90GB unallocated space that it described as Disk 3, Unknown, Not Initialized.  The minutes that had passed since I created the 90GB VHD file were apparently spent actually creating that file in D:\Current.  Evidently this was like the file copying process in Windows Explorer, where sometimes it would say that it had actually gone ahead and copied your 15GB video file to another drive, but what it actually meant was that it was just starting that process, and the new copy would not really exist for a while yet.

Alright.  So now I selected Disk 3, my VHD thing, and went into Action.  Now Attach VHD was not greyed -- it was ready to go.  I clicked on it, to see what would happen next.  Apparently selecting Disk 3 hadn't accomplished anything:  Attach VHD just opened up a dialog asking me where was the file that I wanted to attach.  That made sense -- but then why did Disk Management already show this 90GB unallocated partition?  It seemed like it would have been more logical to show it once I had designated the file that I wanted to attach.  Anyway, I browsed to and selected D:\Current\Win7VHD.vhd and clicked Open > OK.  This gave me an error message:  "The virtual disk is already attached."  So maybe I was right the first time:  as soon as I created the 90GB VHD file, Win7 set aside a logical partition for it, which I was seeing as Disk 3 in Disk Management.  Evidently the Attach VHD option had no real meaning for my present purposes; evidently it had been grayed out because Win7 was then in the VHD-creation process.

So did this mean that Windows Explorer would now display a 90GB unallocated disk?  No.  Well, alright then, could I right-click on the Unallocated area of Disk 3 and format it or something?  No, all options were grayed out except Properties.  Beggars can't be choosers:  I went into that.  There wasn't really anything to adjust there, unless I wanted to turn off write-caching.  Ah, but I could right-click on the left end of the Disk 3 bar, there in Disk Management, and there I did find options:  Initialize Disk, Offline, Detach VHD, Properties, or Help.  It looked all set to let me go ahead and initialize that disk.  So then apparently I would have a 90GB drive, identified with some Windows drive letter -- Q, maybe -- and this drive Q would exist within a 90GB file located in D:\Current.  Kind of an interesting idea.  Probably I could detach it, then, and move it around to some other folder, or maybe even move it without remembering to detach it and thereby crash the system and lose the file and everything in it.  But no, I had faith in Microsoft -- surely they had already anticipated that and would have various protections in place.

It then occurred to me that I had made the drive 90GB because I had an unused 100GB space on my hard drive.  But I was thinking wrong.  The VHD hadn't been created in that unused space.  It had been created in drive D.  I checked the properties for that drive in Windows Explorer.  Sure enough, drive D was a lot more full than it had been 15 minutes ago.  Wherever I was going to be creating VHDs, I needed to make sure I had enough space to play with.  Preferably I would have a space set aside for them, so that I would create and keep them in one place, instead of having to move these gigantic 100GB lumps around all the time, from one drive to another.  I guessed that they could be stored in much smaller spaces on a compressed backup drive, but that trying to run a VHD from a compressed drive would be an extremely slow affair, if such a thing was even possible.

Finally, detaching the VHD gave me the scary option of deleting the disk file.  I was surprised Microsoft put that there.  Oops, my mistake:  there goes 100GB of data.  In this case, I went ahead with it, since I had nothing in the VHD; and for that purpose it was convenient.

So we had the concept of a VHD.  Now, what if I wanted to use a VHD, not just as a storage unit, but as the home of my Windows 7 program files?  In other words, I wanted to boot the system from a VHD.  But how?  That is the topic of a separate post.