CloneVDI tool - Discussion & Support

[mpack]

Beep! Logic error.
nBlocksAllocated == 1MB blocks allocated so far, not max blocks. So a dynamic VDI file size should be exactly nBlocksAllocated*1048576+sizeof(header)+sizeof(BlockMap).

The last two terms add 2MB typ. so can usually be ignored at first approximation - i.e. what I said before.

[wmeyer]

Beep! Logic error.
nBlocksAllocated == 1MB blocks allocated so far, not max blocks. So a dynamic VDI file size should be exactly nBlocksAllocated*1048576+sizeof(header)+sizeof(BlockMap).

The last two terms add 2MB typ. so can usually be ignored at first approximation - i.e. what I said before.

Blocks Total: 92160
Blocks Allocated: 90651

Windows Explorer file size: 45,317,364KB
File Properties Size: 46,404,980,736 bytes

By your formula: 90651 * 1048576 = 95054462976 + sizeof(header)+sizeof(BlockMap)

So? 90GB > 46GB, and that would explain why end of file would overshoot. So I guess the question is, if it's really 46GB allocated in Windows, why does CloneVDI see 90GB allocated so far?

And more to the point, how can I repair this?

[mpack]

So I guess the question is, if it's really 46GB allocated in Windows, why does CloneVDI see 90GB allocated so far?

The header says that 90GB has been allocated to this file, but only 46GB is present. Hence at some point this file was truncated to 46GB, but don't ask me how.

You can't repair a truncated file: the lost data is lost.

If you are not actually seeing any errors then the only repair I can think of would be to reduce the partition size to <46GB, then clone it with compaction enabled. Hopefully CloneVDI would then skip the missing blocks. Be aware however that GParted might crash if it needs to move files which it thinks are stored at the upper end of the disk.

Personally I might consider copying out any files I must have, and delete this disk or VM.

[wmeyer]

You can't repair a truncated file: the lost data is lost.

Well, no, actually, this VM works.

If you are not actually seeing any errors then the only repair I can think of would be to reduce the partition size to <46GB, then clone it with compaction enabled. Hopefully CloneVDI would then skip the missing blocks. Be aware however that GParted might crash if it needs to move files which it thinks are stored at the upper end of the disk.

Personally I might consider copying out any files I must have, and delete this disk or VM.

I have another copy of this VM on a different machine. As these are VMs I use every day, I have found several reasons (including unpleasant Mercurial merge issues) to keep parallel copies.

[mpack]

Um. I don't see where I said that the VM didn't work. In fact my subsequent recommendations make no sense if it doesn't.

[wmeyer]

Um. I don't see where I said that the VM didn't work. In fact my subsequent recommendations make no sense if it doesn't.

OK, data being "lost" was the trigger for my statement. At any rate, I have some issues to resolve on this machine, that much is very clear.

Thanks!

[hakito]

Hi!

I just released a fork for CloneVDI https://github.com/hakito/SlimVDI

Main differences to CloneVDI:

• Support of removing unused blocks for diff images (without merging with base images)
• Work with diff images in command line mode
• Real headless command line mode (without showing a progress dialog)

[mpack]

Why "SlimVDI"? To me that implies a slimmed down version, in comparison to a bloated original. I don't believe that anyone could reasonably consider CloneVDI to be bloated.

I won't comment (much) on your new features because they are kind of alien to me: I created CloneVDI to make cloning easier, because I did not trust snapshots. So, I would never add features which encourage snapshots be used.

[hakito]

Why "SlimVDI"?

Because for me the main feature of the tool is the shrinking of an existing NTFS image, not the cloning. Espescially as cloning can also be done with VirtualBox.

So, I would never add features which encourage snapshots be used.

Anyway, someone may want (or need) this feature though.

[mpack]

Ah, I see, thanks.

[mkamoski]

Dear CloneVDI Author --

Please help.

This tool sounds very good but I am not sure if it will do what I am trying to do.

Here is what I am trying to do.

I have several snapshots in a chain, (ex: Snapshot1, Snapshot2, Snapshot3, Snapshot4, Snapshot5).

See image attached.

(1). I want to retain Snapshot1, Snapshot3, Snapshot5, and I want to delete the rest.

(2). I want to package/save/compact/whatever-it-is-called my result into as few physical files as possible, and I want to have those physical-files be as small as possible, but I want the allocation of the VM space to remain the same (250gb).

So does this CloneVDI tool do that?

Please advise.

Note I am running Virtual Box Manager 5.0.2 and my actual-machine is Windows 10 x64 and my virtual-machine is Windows 8.1 x64.

Thanks.

-- Mark Kamoski

[mpack]

No, my tool will not do that. The clone of a snapshot is always a merge of the complete snapshot chain, so it makes no sense (in the CloneVDI context) to talk about preserving snapshots.

The merged clone will have the same logical disk size as the disk which is represented by the last state in the snapshot chain. If compaction is enabled during cloning then the clone VDI will be reduced to its minimum size.

[mkamoski]

Dear CloneVDI Power Users --

Please help.

I am getting this error...

Go OS Error 0 When Reading From Source File

...and I am not sure why.

The VM is powered off.

Vbox Manager is not running.

Thoughts?

Please advise.

Thanks.

-- Mark Kamoski

[mpack]

I seem to recall that this happens when the VDI has been truncated (shorter than it should be). The error was not anticipated hence it's not worded very well. It's error 0 because no actual I/O error occurred as such, the copy process just reached end-of-file too soon.

Make sure not to copy VDI files on FAT formatted disks, as that will surely truncate them.

[mpack]

NEW VERSION RELEASED - v2.50 (see root message for download link).

Please note that I've released a new version of my CloneVDI tool (v2.50). It has been more than 3 years since the last release (86,000 downloads) and a few minor bugs have been fixed in that time.

In addition CloneVDI now aligns major VDI features (header, blockmap, image) on 1MB boundaries, as VirtualBox itself has done for some time. My old school instincts resent all those wasted bytes, but apparantly this makes the format more suitable for SSDs and 4K sector drives. Personally I would have had the header and blockmap in the first 1MB, and then by all means align the image on the second 1MB boundary.

Another new feature is that I've added support for reading VHDX files. There was no pressing need for this, I was simply curious how Microsoft had addressed the significant shortcomings of the VHD format. The answer is that VHDX, despite the similar name, is a completely different format. In fact it's a bit of a monster, hence support is only experimental for the moment.

Enjoy!