CloneVDI tool - Discussion & Support

[mpack]

No, CloneVDI has an object-oriented design. The compaction function doesn't know or care what container format (VDI vs VHD vs VMDK vs HDD) the disk sectors came from.

When you enable compaction CloneVDI has to inspect the guest filesystem. Locking up would indicate that it found something unexpected there.

Microsoft has a free tool to calculate MD5 checksums. I don't remember what it's called, but no doubt you can Google for it.

[doc_jochim]

When you enable compaction CloneVDI has to inspect the guest filesystem. Locking up would indicate that it found something unexpected there.

7zip created two different checksums without problems, but no md5.

md5-tool from microsoft shows md5checksum without any problems.

André

[mpack]

Uh, the point of a md5 (or any) checksum comparison is the comparison step. You compare the checksum of a suspect file against that of a known good file. If you have a known good copy of a file on PC A then you calculate the checksum there. You then repeat the calculation on the suspect file copy on PC B. If the two checksums match then the files can be assumed to be identical.

Really, I'm getting dragged further and further from the topic of this section, which is CloneVDI. Please try to stay on topic, or find a better topic for your other questions. I said that I would briefly address other matters, and have. The main point here which I've already answered is that CloneVDI getting bogged down while trying to do I/O must indicate an I/O failure of some kind.

[doc_jochim]

ok - concerning the md5-checksum I can only build a checksum and check, if checking doesn't beak but continues to the end. My vhd-file works, but there naturally is no reference-checksum, my file should have, to compare.

But just let's return to cloneVDI an my problem.

Copying and converting 145GB-vhd-file to vdi-file of same size works. But just in the moment that I check the compact-option while copying and converting, there is no more response.

Am I really the first one having this issue? Why me?

Could there be perhaps a problem with the separation of the data-hd into basic partitions, a logical drive and a strange OEM-Partition?

CloneVDI shows the whole harddisk-space as 'source drive information', not only the space of the drive-letter, where the source is located.
Does cloneVDI perhaps has problems to recognize the file systems? Even if three ntfs-drives are installed, cloneDVI only detects two of them?

Attached a screenshot of CloneVDI and the system-information of the harddisk.

cloneVDI

cloneVDI.jpg (73.37 KiB) Viewed 4700 times

Console

drive-management-console.jpg (58.55 KiB) Viewed 4700 times

André

[mpack]

I don't really know what you have there, but that is not an image of a typical XP system disk. XP has no separate boot manager, so there should only be an MBR sector (sector 0 of the drive), and a single NTFS system partition beginning on sector 63, filling the drive. The fact that you have two NTFS partitions, plus two unknown partitions, is worrisome.

Was this an image of a branded OEM system? HP for example? If so then the hidden partitions would be for recovery to factory settings.

The additional NTFS partitions don't count, they aren't really partitions, not primary ones at least. They are nested (logical) partions and I believe the release notes tells you that these are ignored: though it must be said that the use of "logical" partitions in the modern era is unusual (hence why I didn't bother with code to handle them), and I guess CloneVDI could have bugs in this area. Logical partitions were introduced in the DOS era to get us through a brief period where the size of hard disks had outstripped the ability of FAT to handle them efficiently (or at all). XP has no such problem hence in the XP era your "logical partitions" would normally be replaced by folders.

That all said, I would expect CloneVDI to ignore the unrecognized primary partitions which contains the logical partitions. I don't know why it would hang.

Returning to your original question, I believe your best course of action is to run sdelete (inside the guest OS of course) on each partition that you want to compact. Then use the VBoxManage compact feature - or use CloneVDI without the compact feature (*) - and it should work.

(*) CloneVDI always does the equivalent of VBoxManages simple compaction, i.e. it eliminates zero blocks. Enabling the "compaction" option enables additional features which requires it to examine the filesystem. If it works it saves a lot of time. However CloneVDI doesn't always understand the filesystem in use, that's why it's optional.

[doc_jochim]

I don't really know what you have there, but that is not an image of a typical XP system disk.

Pictures of the disk-manager and source drive info don't show my old xp-system, but data disk of my Win10pro64bit.

Separation into different partitions and logical drives is based on the fact, that I first put my xp-system-disk (only system-drive) into *.vhd-container using disk2vhd-tool. Then I cloned my 500GB-Data-HD onto a 1TB-HD using acronis true image. So I always had the possibility to easily return to my old system by simply reusing the untouched old HDs, if something crashes while installing Win7 and upgrade to Win10 onto the new ssd + data-hd. After cloning the data-hd, I created an additional primary Partition inside the unused diskspace to place a temporary systembackup of my laptop-computer. To place the copy of my vhd-container I wanted to create another additional primary partition, but Windows told me about the incapability to handle more than three primary partitions, so the additional drive is created as a logical drive. The existence of the OEM-Partition is a riddle. I don't know why it is there, because the PC isn't a OEM-Computer and Data-Disk was new. Perhaps some change in partitions-size lead to this additional partition. I'll try to delete it and to transfer the free space to an existing partition.

So I had the possibility to format each of the volumes seperately. But you're right. Folders are much more easy to handle...

So far as background-information about the partitions you see at the screenshots - hoping it's not too far off topic.

Returning to your original question, I believe your best course of action is to run sdelete (inside the guest OS of course) on each partition that you want to compact.

I'll try this. Inside the guest-XP there is only one partition. And I'll try to copy the vhd-container to another PC with less partitions and no logical drives - if hanging is caused by host-filesystem, perhaps I can convert and compact it there.

I'll give you feedback.


André

edit:

Was this an image of a branded OEM system? HP for example? If so then the hidden partitions would be for recovery to factory settings.

I just looked at the partition table using partition wizard and must admit that you were right

There was a hidden FAT16-partition at the beginning of the partition table containing DELL-systemtest functions. When I saw this, I remembered that it must have been my XP-systemdisk that i cloned first onto the new drive, followed by the data disk - and that's the reason for the existence of the hidden partition. So I transferred the 2-disk-xp to a bootable 1-disk-xp using different partitions on one drive instead of two physically different drives.

[doc_jochim]

I just corrected the partition table of my data-hdd:
OEM-partition was removed
logical drive was converted into primary partition

So, my data-hdd now has 3 basic partitions

But cloneVDI behaves the same.

Even if I copy my vhd-container to my SSD-System-disk, cloneVDI behaves strange: If I browse to the renamed vhd-container c:\test.vdh as source, cloneVDI shows strange sorce drive information: Drive size is still the size of my data-hdd, file-system is still showing the state before correcting the partitions - simply no change...

Why?

André

[mpack]

These questions and reports are not really about CloneVDI. I suggest that you create a topic and ask your latest questions in a less specialized area, such as Windows Guests.

[doc_jochim]

I don't have a problem with my virtual vhd-container. Everything works except copying and simultaneous compacting using CloneVDI.

But I got it now...

CloneVDI's displayed source-information is not the information of the host-sourcedrive, where the vhd-container is located, but of the container itself.

I started windows disk management inside my guest-xp and remarked that my partition-changes of the host datadrive did not take effect there. There was still the hidden OEM-partition, the logical drive and unchanged partition-sizes.

So I worked on the guest-partitions: I deleted the OEM-partition, deleted unused partition f: and logical drive g:

Shrinking my XP-System into the vhd-container must have copied the partition-table of the whole physical drive, not only from the system-partition - and I previously was of the wrong opinion, that the displayed partitions (additional to my virtualized systemdrive) inside the guestsystem must have been my host-datadrive...

Starting CloneVDI now, displayed source informations doesn't show unknown filesystems anymore, but only one NTFS-System.

And proceeding the task while copying from vhd to vdi and simultaneously compacting the drive, is now showing the progressbar I expected. No more crash and no-response-error.

CloneVDI is working now and perhaps my fault-description and way of solution could help someone else.



Thanks for your patience.

André

[mpack]

Thanks for reporting back.

[hlx]

I've just tried this tool to go from VDI image 32GB to 42GB & clone image
Clicking proceed says how much it written but cloned vdi output is only 2MB
Tool does not appear to check if data is actually written or i've done something wrong. Any ideas on how to debug the problem?

[mpack]

2MB means it contains nothing except the header and blockmap, and the actual entire image is empty. You get that if you clone an empty VDI, for example if you clone the base VDI in a snapshot chain and the first snapshot was created before the VM was even booted for the first time.

Given the complete lack of information given about guest OS, filesystem, partition map, CloneVDI settings, screenshots of folders etc that's the best I can do for now.

[wat]

I see two VMDKs in your source folder. What is the other one?

Also, have you renamed the VMDK file? Please understand that that small descriptor file always exists, and the file which contains the descriptor is the one you need to select in CloneVDI. If you cannot see a small VMDK (i.e. if that other file isn't it) then the descriptor is most likely embedded in the extent file. Either way, that descriptor is at the root of everything and includes a list of the extent files by filename that make up the complete VMDK, in order. The listing may reference an extent by an absolute or relative path, but usually the latter.

The short version: you have an extent file there. Renaming a VDMK extent file is not recommended. If you already renamed it then rename it back. If you want to rename the clone then tell CloneVDI to do it.

Just tried that, clonevdi just adds vdi back to the end of it.

Is vmtools the way to compact vmdk now?

[mpack]

I don't understand your comment. Were you trying to compact a VMDK and expected it to remain a VMDK? It won't - CloneVDI doesn't create VMDKs, it only ever creates VDI. That's because it is designed for VirtualBox, not VMWare. Since VDI is the preferred format for VirtualBox I suggest that you go along with it.

I'm not familiar with anything called "vmtools", so I can't say what you'd use that for. VBoxManage can't compact VMDKs.

[Zeerob]

Hi, I have just downloaded and tried CloneVDI and I ran into a problem that I want to report.
I have cloned a 49 GB VDI with Windows 10. The VDI has just a c: partition (NTFS). It contains a newly created W10-64 Pro installation, with some software installed. I have selected these options:
- Keep old UUID
- Increase virtual drive size to 50 GB (from 48.83)
- Increase partition size
- Compact drive while copying
When I then replace the original VDI file with the clone, the VM starts up ok. Then I have done a disk-check (Properties>Tools>Error checking).
It will say: - You do not need to check this drive ..., but I did it anyway
Then several errors are found:
- Repair this drive. Windows found errors on this drive that needs to be repaired. Close this dialog box, and then repair the drive.

I have then retried it without increasing the drive. Then there were no problems.
Then, I have tried once more with increasing the drive and partition and compacting, but now with 'Generate new UUID', and errors again.

So, it looks as if the combination of all options (Increase drive, Increase partition, Compact) does not work correctly.
Thanks.