Re: Weird Problem with a VMDK file
Posted: 11. May 2015, 18:56
So there was indeed copying of the file going on. Probably several times.
When was all that done? A long time ago, or immediately before you had this problem?
What options did you set in CloneVDI when you asked it to create the clone? I'm puzzled because CloneVDI errored out at 47%, presumably after copying 21.5GB of data. That means that CloneVDI had calculated 100% to mean 21.5/0.47 ==> 46GB (approx). But, that size doesn't match the disk size in your descriptor, which should be all that CloneVDI cares about. Wrong descriptor perhaps?
Following that track, where did you get that VMDK descriptor? "Sparse" VMDK descriptors are usually embedded within the file. Certainly that would be the case for VMDKs created by "VBoxManage clonehd". I'm wondering if you have two descriptors (one internal, one externa), and a mismatch between their claimed sizes.
Does CloneVDI let you open and clone the "COOJA.vmdk" file? If it does then the latter is your actual VMDK, and you've been mistakenly mixing an old descriptor with a new all-in-one VMDK.
When was all that done? A long time ago, or immediately before you had this problem?
What options did you set in CloneVDI when you asked it to create the clone? I'm puzzled because CloneVDI errored out at 47%, presumably after copying 21.5GB of data. That means that CloneVDI had calculated 100% to mean 21.5/0.47 ==> 46GB (approx). But, that size doesn't match the disk size in your descriptor, which should be all that CloneVDI cares about. Wrong descriptor perhaps?
Following that track, where did you get that VMDK descriptor? "Sparse" VMDK descriptors are usually embedded within the file. Certainly that would be the case for VMDKs created by "VBoxManage clonehd". I'm wondering if you have two descriptors (one internal, one externa), and a mismatch between their claimed sizes.
Does CloneVDI let you open and clone the "COOJA.vmdk" file? If it does then the latter is your actual VMDK, and you've been mistakenly mixing an old descriptor with a new all-in-one VMDK.