Booting StreamOptimized VMDK

[mpack]

No, the "incrX.vmdk" files you sent last time were not data volumes either. That would require them to be partitioned and formatted, which they don't seem to be.

I verified that they were not child/difference images by virtue of the fact that CloneVDI was happy to open them, which it couldn't do if they were either compressed or if it thought they were part of a difference chain any element of which was compressed.

Come to think of it though, CloneVDI has a "Show Header" feature which should settle the matter, let me just check that... Hmm. The incrX VMDK header type is "monolithicSparse" which indicates a single file, dynamically allocated format - equivalent to a VDI. However, it has a parent signature field set (note: not a parent UUID). CloneVDI doesn't recognize this as a difference image, I don't know if VirtualBox would - I don't meet many differenced VMDKs, certainly not of this variety.

Summary: it looks like the incrX disks are child disks, but not of the kind which I've seen VirtualBox use - and I don't know if VBox supports this kind.

[vigneshrams]

Hi,

Thanks for the reply. How can i boot compressed VMDK in virtual Box. Is there anywork around for it. Does it require Code change to make it boot. Please help on this.

/ Thanks

[mpack]

I don't understand. In an earlier message of this thread you said that you were already able to boot from a compressed VMDK.

If you're asking how to make a permanent VM from it, then I suggest you convert the compressed VMDK to a normal VDI, then build a new VM around the VDI in the normal way.

[vigneshrams]

HI,

Thanks for the reply. Yes as i mentioned eariler i was able to boot from compressed full VMDK but i am not boot the compressed incremental VMDK without coversion process.
Is there a way for it? Or somechanges in the code will make it happen ? Any help on this

/Thanks

[mpack]

It seems to me you can easily test that for yourself. First mount the parent VMDK in a VM. Then mount the child VMDK in the same VM, replacing the base VMDK - which remains registered even though not mounted.

If VirtualBox accepts that then you'll have a working VM. If VirtualBox will not accept it then nothing else be done about it short of you taking the source code and modifying it yourself.

Even if it works it qualifies as a novel structure and hence more likely to encounter problems.

What's so important about using compressed VMDKs anyway? You won't save any disk space this way - all the writes will just go difference files instead.