Diskpart Takes Snapshots of Physical and Virtual Systems

In "Diskpart Goes Virtual" (InstantDoc ID 103685) and Diskpart Exerts VHD Control (InstantDoc ID 125054), I showed you how to configure virtual hard disk (VHD) files on your Windows Server 2008 R2 or Windows 7 system—just like installing actual physical disks. Clearly, the "V" in VHD is a little misleading, as we use VHD files in physical rather than virtual machines (VMs).

But one of the coolest things about VMs is the ability to create snapshots that remember the VM's current state. You can return to a snapshot at any time by "rolling back" the VM. Server 2008 R2 and Windows 7's VHD support provides that sort of snapshot capability, letting you create VHDs and attach them as drives whose entire contents you can roll back at a moment's notice—sort of a "virtual do-over." The capability just requires a bit of clever Diskpart work. But the work is worth it, letting you extend the simplicity, speed, and power of VM snapshots to data volumes and even system volumes. That's right—you can snapshot a physical rather than a virtual machine.

Parenting the Child

To get Diskpart to do that work, however, you need to understand the way Microsoft thinks about snapshots. Suppose you have a drive P: that's actually a VHD, and you want to give it the snapshot capability. In Microsoft parlance, you do that by employing two VHDs—one called the parent and the other called the child.

In this model, you'd call P's original VHD the parent VHD. To make P: snapshot-capable, you wouldn't do anything to the parent; instead, you'd use Diskpart to create a second VHD called a child VHD. (When you create the VHD, you must inform Windows that the new VHD is a child and you must identify the name of the parent VHD.) You then tell Windows to no longer attach the parent as P, because to get snapshot functionality, you must attach the child VHD, which automatically becomes P. Assuming that the parent VHD is called e:parent.vhd and the child is named e:child.vhd, you'd type the following commands to detach the parent, create the child, and attach the child:

select vdisk file=e:parent.vhd
detach vdiskcreate vdisk file=e:child.vhd parent=e:parent.vhd
select vdisk file=e:child.vhd
attach vdisk

You detach the parent first because you can't create a child to a parent VHD if that parent is currently attached. Notice that the syntax to create a child VHD is simple. You need to know only two things about the command: First, you can create a child VHD only from an expandable parent; if your would-be parent VHD is of a fixed size, you can't create a child for it. Second, don't specify a size for the child VHD; a child VHD can't grow beyond the size of the parent.

The next two commands simply select and attach the new child. After this process, drive P appears again. From a user's perspective, you really have no idea that you're working with a child instead of a parent. (That being said, performance will probably be a bit slower than working with the parent, although I don't have comparative speed measurements.)

Rolling Back

Now that you have a drive that can be rolled back, how do you do it? You can either tell Windows to roll back P to its pre-child state (i.e., delete all changes) or tell Windows to incorporate child.vhd's changes into parent.vhd (i.e., accept all changes).

To tell Windows to forget anything that you did to child.vhd and to essentially roll back the changes to P, just detach child.vhd and re-attach parent.vhd, as in

select vdisk file=e:child.vhd
detach vdisk
select vdisk file=e:parent.vhd
attach vdisk

At this point, child.vhd is of no value; you can delete it. If, on the other hand, you're happy with the changes you've made to P under the guise of child.vhd, use the Merge Vdisk command. To do that, you must first detach the child VHD (if it's currently attached), then select that VHD (which might not be necessary but can't hurt), then use the Merge Vdisk command to stuff child.vhd's changes into parent.vhd, and finally re-select and re-attach parent.vhd. Again, you can now delete child.vhd, as it's superfluous at this point. Here's the syntax:

select vdisk file=e:child.vhd
detach vdisk
merge vdisk depth=1
select vdisk file=e:parent.vhd
attach vdisk

To merge child.vhd into parent.vhd, just make sure that neither child nor parent is attached, then select the child and use the Merge Vdisk command. Now, you can just use the parent.

Applying It

How might you use this capability? Now and then, I want to try something out without screwing up a working system, but for some reason it's not wise to use a VM for the tests. With this snapshot feature, you can run your app on a physical machine but keep the data virtual. And heck, you can even extend the notion of virtual-like snapshots to an entire physical machine! But that's a story for next month.