Compaction of a volume placed on a dynamic VHD will result in smaller offline image. It however has nothing to do with resizing a VHD file (once the underlying volume has been compacted and is now smaller in size than VHD file) that can be done for fixed and dynamic VHDs. Compacting content and resizing a VHD file - two separate independent operations.
Lets get this clarified from the beginning. This is how I see it:
VHD is a
file format that describes the contents of a physical hard drive. Let's call it a "container" because it
contains an image of a hard drive.
Now the hard drive that is
contained by one (or more) VHD files,
contains disk partitions which
contain file systems, which in turn can contain files and folders.
VHD is to disks, what ZIP is to files.
And keep that in mind for this analogy:
Lets imagine that I zip up all my porn, which I keep as BMP files, and send them to Wonko. And lets say I only use the minimum compression option of ZIP.
Now Wonko has my porn, and he wants to send it to his friend, but the file is too big. He can do (at least) three things to make it smaller:
- He can rezip using a higher level of compression.
- He can convert all the images to JPG and rezip them.
- He can delete the she-male directory from the ZIP file.
In case 1, that's clearly something a ZIP utility would do.
In case 2, that's clearly nothing to do with the ZIP utility, and is something Wonko will have to do with some other program.
In case 3, the ZIP utility will do the work, but essentially what it will do is:
- Create a new ZIP file
- Copy all the files that aren't she-male porn, into a new ZIP file
- Copy the new ZIP file over the original ZIP file, and delete the copy it made.
Bringing this all back to VHD images, we have what I consider to be the some of the thing that "VHD One" (working name) will and will not do.
- It will (using existing WMI function) reduce the size of a VHD, if possible. (i.e. if the WMI interface can do it).
- It will not make modifications to partitions or other objects contained within the VHD.
- It may permit the removal of entire partitions from the VHD, in so far as the WMI for Disk Management allows.
It will not manipulate partitions, that is, it
will not:
- De-fragment a volume
- Remove files from a volume
- Reduce the size of a volume or partition
- Change the location of a partition
The reason it will not do these things, is that they are outside the scope of what a VHD container is. You wouldn't expect ZIP to convert BMP files to JPG to reduce the size of an archive, and you shouldn't expect a VHD utility to start messing with partitions sizes, or file allocation.
A ZIP utility only has to
contain files and directories. It doesn't care what's inside those files. It just has store their names, and their contents.
A VHD utility only has to
contain an image of a
DISK. Anything within that disk, including entire partitions, are not within the purview of the VHD specification. The contained disk is not guaranteed to contain NTFS partitions, it may not even contain partitions as we know them. It may be an image of Macintosh LS III from 1995, with an Apple Partition Map.
So if you're after "real" VHD compression, you'd be well advised to obtain a copy of something like Acronis Disk Director, which is quite capable of reducing the size of a partition to the bare minimum required to store the files.
If you do that, and the VHD in question is of a fixed size, then the WMI VHD functions will still not permit you to compact the size of the VHD. However, I will look into the possibility of achieving this within the WMI framework, perhaps using the equivalent of the DISKPART command:
create vdisk file=<file path=""> [source=<file path="">] [maximum=<n>]
</n></file></file>
And if it is a simple "hack" to change the length of a VHD file, I may include that ability. I'm not against functionality, just hard work.