Jump to content











Photo

Boot Win 7 VHD on Bare Metal PC from Empty Drive

vhd bare metal boot win 7 grub4dos

  • Please log in to reply
321 replies to this topic

Poll: Are you interested in booting Windows from VHD? (86 member(s) have cast votes)

Would you try to install OS to and boot from a single portable VHD file (virtual disk) instead of hard drive?

  1. Yes (83 votes [96.51%])

    Percentage of vote: 96.51%

  2. No (3 votes [3.49%])

    Percentage of vote: 3.49%

Would you be interested to copy that VHD file to an empty USB Thumb or HD and boot from it on real PC?

  1. Yes (82 votes [97.62%])

    Percentage of vote: 97.62%

  2. No (2 votes [2.38%])

    Percentage of vote: 2.38%

Did you try to boot OS from VHD on real PC instead of Virtual Machine?

  1. Yes, I usually boot VHDs saved on an internal hard drive (36 votes [38.30%])

    Percentage of vote: 38.30%

  2. Yes, I usually boot VHDs saved on a USB drive or thumb (11 votes [11.70%])

    Percentage of vote: 11.70%

  3. Yes, I boot VHDs saved on drives of any type (13 votes [13.83%])

    Percentage of vote: 13.83%

  4. Not yet (34 votes [36.17%])

    Percentage of vote: 36.17%

Vote Guests cannot vote

#51 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 November 2011 - 05:29 PM

I remember reading somewhere that when system volume size is changed in a hard disk IMG file, Win can't boot any longer from that image until adjusted. Not sure why, but may be someone working with hard disk IMG files can explain. That isn't generally true about system volumes on physical drives. But after resizing a VHD file the same thing often happens, even if resizing its volume in Disk Management and then shrinking the file in VHD Resizer - the cause needs to be clarified too.

I guess you are thinking of the way drive letters are coupled with volumes.
The thing is based on Disk signature and offset of beginning of the partition/volume, so it is unlikely that either is going to be changed when just resizing a "first partition" unless for any reason you are also re-aligning it, as an example operating on a partition with a tool that does not respect cylinder boundary (but "original" partition was cylynder boundary aligned) or viceversa.
Details:
http://www.911cd.net...showtopic=19663

XP and earlier default to cylinder boundary aligning.
Vista :ph34r: and later default to sector/cluster aligning.
When mixing tools terrible things may happen:
http://reboot.pro/9897/

:cheers:
Wonko

#52 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 21 November 2011 - 10:42 PM

So, if one backups a system partition to VHD with Disk2VHD, and the app will copy the whole drive with its partition structure, but leave other partitions empty, one would want to have them deleted and the VHD shrinked with VHD Resizer to the boundary of the backup-ed volume. Two things may go wrong:

1) partition layout on disk changes or a new GUID is assigned, and hence requires BCD update
2) a Resizer re-aligns the volume, hence requiring MBR update reflecting disk geometry changes

How to allign properly a volume on VHD that was re-aligned and doesn't boot anymore?

#53 sfinktah

sfinktah

    Frequent Member

  • Advanced user
  • 217 posts
  • Location:Der Äther
  • Interests:/(C(++|#)|P(HP|XE)|(OS|Linu)X|8051)/
  •  
    Australia

Posted 21 November 2011 - 11:12 PM

I remember reading somewhere that when system volume size is changed in a hard disk IMG file, Win can't boot any longer from that image until adjusted. Not sure why, but may be someone working with hard disk IMG files can explain. That isn't generally true about system volumes on physical drives. But after resizing a VHD file the same thing often happens, even if resizing its volume in Disk Management and then shrinking the file in VHD Resizer - the cause needs to be clarified too.

As to including expandable VHDs - the tool should allow to do as a minimum everything Disk Management Console can do with VHDs and more, and that includes of course working with dynamic and (guess what ../public/style_emoticons/default/smile.png) differencing VHDs. If resizing is limited to making a smaller or larger VHD file copy after resizing its underlying partition, it should be no problem to include as well.

Of course, a physical drive where VHD is saved should have enough free space to hold a dynamic VHD when maxed out or booted from. Dynamic VHDs are quite attractive, when carrying several different OSs in VHDs on an external small drive or USB Thumb - because only one OS can boot at a time, so total space required is much less then sum of maxed dynamics. The physical drive should also have extra space for redirected Paging files.


I have a suspicion that the same rule about dynamic VHDs and free disk space, may apply to a differencing VHD. At least, that's the last guess I have as to why mine won't work.

I can see how VHD Resizer might cause issues with the BCD, since it's generating a totally new image and it probably has a new internal GUID. But I've also discovered that Visual BCD Editor is the answer to all such problems... and now that I'm proficient with it, I really don't need to touch bcdedit.exe again - unless I'm doing a real bare-metal install.

With your VHD drives mounted, it generates all the required boot entries (if needed), and doesn't alter any existing ones. All you have to do is add the DetectHal option, and you're good to go. I just added a 2K8R2 and a Tiny7 VHD to one of my machines, using only DISKMGMT.MSC to create the empty VHDs, IMAGEX to /Apply the install.wims to the respective VHDs, and Visual BCD to add the boot entries.

It's certainly not hard to replicate the VHD capabilities of DISKMGMT, which are a subset (?) of DISKPART anyway, and both just use calls to the VHD WMI.

There's not really very much you can do to differencing VHDs, there's creating them, deleting them, merging them, and copying (which is just a merge to a new destination). All this is part of DISKPART too, and falls under the same WMI (windows management interface), so it's no big deal to code.

Just don't get any ideas about resizing differencing VHDs. And if you want to seriously resize a stand-alone VHD (dynamic, or allocated), you will have to get your hands dirty. If you wanted to really squeeze all the space out, I'd be seriously considering an "xcopy /s" (or robocopy, or imagex, or whatever) of the files to a brand new VHD. That's probably the hardest bit... and I can see myself not coding that.

After that, there is including what Visual BCD Editor does, in terms of upating the BCD to match your VHD collection.

Does that about sum it up?

#54 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 November 2011 - 05:11 AM

I have a suspicion that the same rule about dynamic VHDs and free disk space, may apply to a differencing VHD. At least, that's the last guess I have as to why mine won't work.

No, Diff VHDs have no defined size (except max 2 Tb), and merely reflect subsequent disk sector changes compare to "Read Only" Base VHD. Don't forget, Diff and Base VHDs must be kept in the same folder for native boot on real hardware. If you try instead to boot a Diff VHD inside a VM attached as IDE hard drive, you may want to check with Hyper-V Help what rules apply and look through these Guides:

Hyper-V Virtual Machine (VM) Parent-Child Configuration Using Differencing Disks
Using Existing Virtual Hard Disks with Hyper-V
Modify a virtual hard disk in Windows 7 Virtual PC

Still better to keep Base and Diffs in the same folder of a physical HD. If you use a VM other than Hyper-V 2008R2 or Win7 Virtual PC, it might have own support issues with latest VHD format - hence, install standalone Hyper-V or Win Server 2008R2 (and activate its Hyper-V role) or Win7 VPC, while developing this app. I suggest Hyper-V, since VMs created in VPC must be generalized to run in Hyper-V (didn't try to run them on real HW), and VPC interface really socks (if you can't start it - look for VPCWizard.exe in system32).

Just don't get any ideas about resizing differencing VHDs. And if you want to seriously resize a stand-alone VHD (dynamic, or allocated), you will have to get your hands dirty.

Before one creates a Diff VHD, it makes sense to defrag, compact and shrink the partition on its Base VHD and then resize the VHD file. For shrink (as opposed to expand) MS doesn't openly unveil any support, but you may want to ask this Virtual PC Guy. Hence these features is desirable to include in the app - at least defrag and compact (for Base fixed and dynamic VHDs). The task remains to make sure, resizing if included doesn't adversely affect ability to boot OS on the VHD. In that respect, its interesting to learn, how changes in VHD geometry reflected in its footer and changes to it's OS partition geometry reflected in MBR affect boot from VHD.

This .NET DiscUtils package can support resizing (disk copy) features in your app. See also PowerShell Management Library for Hyper-V and How to Perform Common Tasks for Virtual Hard Disks. I'd suggest to leave mentioned below "mismatch check & fix" features for later, and concentrate for now on basic tool features you listed above. :)

However, for the future:

Its desirable to also incorporate a check & fix for any partition layout mismatch in BCD compare to actual layout, which may result from the copy operation. Apparently, Windows Repair can update the partition layout data in BCD, thus requiring no volume re-alignment (i.e. no data moving required) - it would be nice to find out, how exactly it does that (see for example Diskpar.exe).

Also, Visual BCD Editor doesn't seem to support locate command so far (try using it), which is quite important for multi-drive and portable USB setups. And its desirable to incorporate Disk Signature mismatch check & fix in case a VHD was mounted on the same PC with source OS drive attached, or two cloned VHDs were mounted simultaneously, and the Signature of one of them was changed by OS to avoid disks collision.

#55 Uvais

Uvais

    Frequent Member

  • Advanced user
  • 180 posts

Posted 22 November 2011 - 05:22 AM

tut rocks :good:

#56 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 November 2011 - 09:28 AM

How to allign properly a volume on VHD that was re-aligned and doesn't boot anymore?

It depends on:
  • which OS is running (XP/2003 or earlier vs. Vista :ph34r: or later, "pached" or "non-patched" about alignment)
  • which specific tool is used to shrink/enlarge/move the partition
You should check how the tools and OS you use behave and - depending on it - try using another tool or another method.
In the worst case, you can do it "manually" with dsfo/dsfi and a hex editor.
You have to imagine a partition (once it has a fised size) inside a disk image like a "block" that you can move forward and backward within the limits of the disk.
The "address" of this block is in TWO places:
  • the MBR partition table
  • the PBR
nothing prevents you to add or remove sectors between the MBR and the PBR or between the end of the partition and the end of the disk image. (as long as you later correct those addresses)
In the case of a .vhd there is also a THIRD place, to be aware of, the .vhd footer.
Easiest would be to remove it (thum making the .vhd become a simple RAW .img) do the modifications, then tre-create the .vhd footer.
Of course the above only applies to a "Static" .vhd, the other types should work with more or less the same principles, but the procedure may be much more complex.

:cheers:
Wonko

#57 nedbert9

nedbert9
  • Members
  • 2 posts
  •  
    United States

Posted 22 November 2011 - 10:04 AM

Re: VHD disk geometry changes and possible BCD impact

I have no idea if a disk geometry change would affect BCD.

A resize changing the starting offset sounds...wrong. However, it is creating a new VHD, then copying, right? So, it's a possibility.

It doesn't sound like there will be a simple tool, such as diskpar, that would address the problem of a new VHD with a differing starting offset from the original. If the data is written at a new offset, then data will have to be moved when re-aligning. Sounds like the resizer tool puts you in an awkward position.


Well...after a little brain spark I researched offset change plus data move with DD. Didn't come up with something DD specific, but a linux tool.

http://forums.crucia...-loss/td-p/4829

A Windows based option (create a compressed WIM - see option 3. You might want to look at this option as a complete replacement for resizer since it seems to duplicate the entire function/need)

http://myitforum.com...king-a-vhd.aspx


This thread has been a great read. I've learned a lot about the new boot style since I've been out of the loop for a few years.

Good luck

#58 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 November 2011 - 02:44 PM

Easiest would be to remove it (the VHD footer - thus making the .vhd become a simple RAW .img) do the modifications, then re-create the .vhd footer.

Any tools suggested for this, and/or a thread explaining how to determine whether a system volume mis-alignment exists in an IMG file and how to correct it?

nedbert9

Thanks for important links!

#59 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 November 2011 - 05:18 PM

Any tools suggested for this, and/or a thread explaining how to determine whether a system volume mis-alignment exists in an IMG file and how to correct it?

What do you mean tools? :unsure:
Clonedisk can create/add or remove the footer allright.

You check the start address of the CHS address in the partition table of the MBR, and the LBA "Sectors Before" or "Start" and the "Hidden sectors" or "Sectors Before" in the BPB of the bootsectors (these latter ones are the same and are the actual value that goes in the Registry for drive letter).
These values in a "normal" disk structure - single primary partition on disk - with geometry 255/63 are ("classical convention"):
  • CHS start 0/1/1
  • LBA 63
  • BPB 63
and in the new Vista :ph34r: paradigm:
  • CHS start 0/32/33
  • LBA 2048
  • BPB 2048
As said, I doubt that shrinking a partition will change those values unless two tools using a "different convention" are used :dubbio:.
But, as long as the two values CHS/LBA in the MBR are "balanced" and the bootsector has the same value, one cannot say that either is "mis-aligned", they are simply "differently aligned".
Not respecting Cylinder alignment may be a problem for some BIOSes and for some legacy OS, that still use CHS but nothing more.

An interesting exception are the FAT32 and NTFS bootsectors of XP/2003 that also check the H/S geometry, see here:
http://www.911cd.net...ic=21702&st=129
http://reboot.pro/8528/page__st__21
(cannot say if this issue affects the Vista :ph34r: or 7 bootsector though)

AFAIK/AFAICR, all .vhd's use the default H/S geometry of 255/63 so this should never be a problem, and in any case it should be unrelated to drive letter assignment. (but this not necessariy has connections to the BCD stuff)

To simplify, in the above mentioned examples you have a "no man's land" that is either 62 or 2047 sectors in size between the MBR and the PBR.
If you had an original IMG with partition that started at offset 63 and the tool changed this to 2048, you simply remove (2047-62)=1985 sectors from this area and correct the three mentioned addresses (and the CHS End address - if applicable[1])
If you had an original IMG with partition that started at offset 2048 and the tool changed this to 63, you simply insert (2047-62)=1985 sectors in this area and correct the three mentioned addresses (and the CHS End address - if applicable[1])

BUT we have not right now any actual evidence that such a re-alignment happens (and with which tools/procedure it happens and with which tools/procedure it does not).

The issue with shrinking or expanding may be (though not related to the drive letter assignment in the Registry) also with the end of the partition alignment.
The "old" convention used anyway a cylinder boundary, if you prefer you could create a partition (or resize an already aligned one) in 8 mb steps, i.e. 1x255x63x512=8,225,280 bytes, the "new" convention can have theoretically only a cluster size step.

@nedbert9
Yes, IF the resizing tool actually "cheats" and creates a new image it is entirely possible that some other data (Disk Signature and Volume Serial in primis ) become different, still no idea how this would be connected to the BCD entry, though.

:cheers:
Wonko


Notes:

[1]If applicable means "if the partition size is smaller than around 8 Gb", otherwise these are "fixed" to 1023/255/63.

#60 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 November 2011 - 05:38 PM

IF the resizing tool actually "cheats" and creates a new image it is entirely possible that some other data (Disk Signature and Volume Serial in primis ) become different, still no idea how this would be connected to the BCD entry.

There is binary data relating disk signature and partition layout stored in BCD. It must be updated, when changes with a referenced in BCD volume occur.

I mean tools like Diskpar.exe (for fixing partition layout).

#61 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 November 2011 - 06:03 PM

There is binary data relating disk signature and partition layout stored in BCD. It must be updated, when changes with a referenced in BCD volume occur.

Sure. :)

I mean tools like Diskpar.exe.


Well, no.

Diskpar is/was a "destructive tool", and it's functionalities are superseded by the Diskpart ones:
http://geekswithblog...8/11/49948.aspx
Diskpar is/was about alignment (and has nothing to do with Disk Signature), while Diskpart (as in the mentioned blog):
http://blogs.technet...08/3463572.aspx
can change the disk signature (like a whole range of disk utilities).

If you prefer, in Server 2003 "default" was "old" convention, and a "special tool" (Diskpar) was provided to partition disks with the new convention, then Diskpart was updated to include the new functionalities and with Vista :ph34r: the "default" became "new" convention.

Still, unless there is a signature collision, there is no sense for a resizing tool to change the disk signature.

:cheers:
Wonko

#62 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 November 2011 - 07:03 PM

I wonder if Diskpar can & makes sense to use for checking and eliminating Win7 volume mis-alignment on a resized VHD. Another tool (or Diskpar?) might be used to get current VHD disk Sig. Then Diskpart can be called to update BCD with new partition info and disk Sig for the VHD. Such sequence would allow to automate the disk fix & BCD update process in VHD Manipulator, when disk alignment and/or Sig changes during Resize process or after mounting VHD on the source volume PC.

#63 nedbert9

nedbert9
  • Members
  • 2 posts
  •  
    United States

Posted 22 November 2011 - 07:12 PM

I wonder if Diskpar can & makes sense to use for checking and eliminating Win7 volume mis-alignment on a resized VHD. Another tool (or Diskpar?) might be used to get current VHD disk Sig. Then Diskpart can be called to update BCD with new partition info and disk Sig for the VHD. Such sequence would allow to automate the disk fix & BCD update process in VHD Manipulator, when disk alignment and/or Sig changes during Resize process or after mounting VHD on the source volume PC.


I'm pretty sure both DISKPART and DISKPAR have options for displaying the first partition starting offset. It's just that DISKPAR is a very focused tool and legacy, so it's not a great option for a new development.

I'm curious. Are you guys planning on using the ...WMI API? for VHD shrinking? I suppose if the VHD API covers the need then my suggestion of using Imagex /capture to create a compressed copy, then /apply to a VHD created by your automation with the desired partition offset is not a better option.

#64 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 November 2011 - 07:20 PM

Some other tools for the job are mentioned here. Besides, your link says, the ImageX method is unreliable for shrinking VHDs. And, can it capture optimally a WinXP volume? :)

#65 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 November 2011 - 08:32 PM

@Sambul61
As said Diskpar can ONLY create a new partition (with a given offset), so it is of NO use if not to check current alignment of a given image.

But it is much simpler to check the offline image.

Quick example (checking just the LBA Start Address or "Sectors Before" in the MBR):
@ECHO OFF

::Usage: chkalign.cmd <filename> where filename is a partitioned disk image

For /F "tokens=2,3,4,5 delims= " %%A IN ('dumphex /s01c6 /L4 /nc %1') DO (

IF "%%D%%C%%B%%A"=="0000003F" ECHO First partition is aligned to 63 sectors&GOTO :EOF

IF "%%D%%C%%B%%A"=="00000800" ECHO First partition is aligned to 2048 sectors&GOTO :EOF

ECHO %%D%%C%%B%%A & ECHO "Partition is NOT aligned to 63 or 2048 sectors

)




Dumphex:
http://rbach.priv.at/DumpHex/

:cheers:
Wonko

#66 sfinktah

sfinktah

    Frequent Member

  • Advanced user
  • 217 posts
  • Location:Der Äther
  • Interests:/(C(++|#)|P(HP|XE)|(OS|Linu)X|8051)/
  •  
    Australia

Posted 23 November 2011 - 11:51 AM

bootbcd is a registry hive. Load offline file and compare raw data.


Thanks, I was wondering what I was going to do with the exported backup of the BCD :) It will be good to nail this one down and make a quick function to test the validity of the BCD entries. It really does suck to have to wait until reboot to get some non-specific error code.

#67 sfinktah

sfinktah

    Frequent Member

  • Advanced user
  • 217 posts
  • Location:Der Äther
  • Interests:/(C(++|#)|P(HP|XE)|(OS|Linu)X|8051)/
  •  
    Australia

Posted 23 November 2011 - 12:07 PM

I'm curious. Are you guys planning on using the ...WMI API?

Yes.

for VHD shrinking?

Not for fixed sized images.

I suppose if the VHD API covers the need then my suggestion of using Imagex /capture to create a compressed copy, then /apply to a VHD created by your automation with the desired partition offset is not a better option.


What the API says, is this:

Compaction can be run only on a virtual disk that is dynamically expandable or differencing.

There are two different types of compaction.

  • The first type, file-system-aware compaction, uses the NTFS file system to determine free space. This is done by attaching the VHD as a read-only device by including the VIRTUAL_DISK_ACCESS_METAOPS and VIRTUAL_DISK_ACCESS_ATTACH_RO flags in the VirtualDiskAccessMask parameter passed to OpenVirtualDisk, attaching the VHD by calling AttachVirtualDisk, and while the VHD is attached calling CompactVirtualDisk. Detaching the VHD before compaction is done can cause compaction to return failure before it is done (similar to cancellation of compaction).
  • The second type, file-system-agnostic compaction, does not involve the file system but only looks for VHD blocks filled entirely with zeros (0). This is done by including the VIRTUAL_DISK_ACCESS_METAOPS flag in the VirtualDiskAccessMask parameter passed to OpenVirtualDisk, and calling CompactVirtualDisk.
File-system-aware compaction is the most efficient compaction type but using first the file-system-aware compaction followed by the file-system-agnostic compaction will produce the smallest VHD.


However, at this stage of development, my primary focus is designing the application's icon.

#68 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 23 November 2011 - 12:34 PM

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.

#69 sfinktah

sfinktah

    Frequent Member

  • Advanced user
  • 217 posts
  • Location:Der Äther
  • Interests:/(C(++|#)|P(HP|XE)|(OS|Linu)X|8051)/
  •  
    Australia

Posted 23 November 2011 - 01:03 PM

I would like to thank Wonko the Sane for this amazing art work, with which this project may never have been possible.

Posted Image

#70 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 November 2011 - 01:27 PM

I would like to thank Wonko the Sane for this amazing art work, with which this project may never have been possible.

Posted Image


I don't get it. :unsure:
Care to explain? :dubbio:


:cheers:
Wonko

#71 sfinktah

sfinktah

    Frequent Member

  • Advanced user
  • 217 posts
  • Location:Der Äther
  • Interests:/(C(++|#)|P(HP|XE)|(OS|Linu)X|8051)/
  •  
    Australia

Posted 23 November 2011 - 02:06 PM

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.

#72 sfinktah

sfinktah

    Frequent Member

  • Advanced user
  • 217 posts
  • Location:Der Äther
  • Interests:/(C(++|#)|P(HP|XE)|(OS|Linu)X|8051)/
  •  
    Australia

Posted 23 November 2011 - 02:10 PM

I don't get it. :unsure:


Posted Image

#73 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 November 2011 - 02:41 PM

Yes, I know what an icon is, but thanks :)
But since I did not provide an icon, the question was why you named my name (in vain) connected to the lousy screenshot you posted (which includes a - lousy too IMHO - B/W icon)? :unsure:

Your comparison of VHD format with ZIP is interesting, though some - not so trivial - details must be specified.
There are three types of VHD's:
  • Static
  • Dynamic
  • Differencing
The first type is nothing but a RAW disk image with a single description sector appended to it.
There are three sub -cases for it:
  • the disk image is "filled to the brim" by one (or more) partition(s)
  • there is some "unused space" at the end of it
  • there is some "unused space" after the MBR and before the PBR of first partition (with the exception of the "normal" 62 or 2047 hidden sectors), as an example you create two parittions on the disk and later you delete first one.
IMHO:
In case 1.1 (probably 99% of commonly used VHD's) there is no possible way to reduce the size of the image file without touching the inner partition data.
In case 1.2 it is trivial to truncate the image after the last sector used and re-add the footer
In case 1.3 there is no possible way to reduce the size of the image without touching the inner partition data.

I am not familiar with Dynamic or Differencing VHD's, but if you don't touch their contents I doubt that you can in any way reduce their size. :unsure:

:cheers:
Wonko

#74 sfinktah

sfinktah

    Frequent Member

  • Advanced user
  • 217 posts
  • Location:Der Äther
  • Interests:/(C(++|#)|P(HP|XE)|(OS|Linu)X|8051)/
  •  
    Australia

Posted 23 November 2011 - 03:32 PM

Well...after a little brain spark I researched offset change plus data move with DD. Didn't come up with something DD specific, but a linux tool.

Good luck


I [heart] dd. This is how I distributed my 20GB sysprepped "Crysis II & Win7 on a stick" distribution:




   diskutil unmountDisk disk10

   cat sdb-mbr sbd-hidden-data-after-mbr | dd of=/dev/rdisk10 bs=512

   cat sdb1.dd-img.a? | xz -d | dd of=/dev/rdisk10 bs=1048576 seek=1 conv=notrunc




(it's a Mac thing)

#75 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 23 November 2011 - 03:47 PM

sfinktah

Currently available tools like VHD Resizer appear to do just that: copy a VHD file to a smaller file, if a disk or volume image inside it is smaller than the file. I think it's easy to implement in VHD One (if you like this name). :)

You might still be interested to ask VirtualPC Guy (really in his Blog or by email), why they don't offer API for such a basic scenario, despite offering similar Expand feature.

Since we're deep into porn zipping, I get curious how one can compact a zipped porn. :confused1: Can you clarify in the same clear manner, what exactly happens during compaction (that might be accompanied with precompaction)? :photo:





Also tagged with one or more of these keywords: vhd, bare metal, boot, win 7, grub4dos

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users