VMDK monolyticSparse Usage

[MVS]

Thanks for your reply

I want to know one more thing here, can i boot incremental VMDK [child disk] which is of disk type monolithic-sparse in virtual box. I tried booting it but failed with black screen error. Is there any way to boot the incremental VMDK ?

Regard's
MVS

[noteirak]

incremental means what only what changed from the parent image is present, so you'll never have al the data and won't be able to use it like that. You must have the whole chain of disk to work.

[MVS]

Thanks for your reply

We have a chain of VHDs in the same folder and we are able to successfully boot it in the Virtual Box by selecting the last incremental backup from the VHD chain. But when we trying the same with the VMDKs it fails., Is there any specific reason for the failure or is there any preconditions that need to be set to boot the VMDK Incrementals ?


Regard's
MVS

[noteirak]

Do you have an error message in your black screen?

[MVS]

Yes, After attaching incremental vmdk incremental file, if i start the virtual machine i am getting this error message

"FATAL: No bootable medium found! System halted."

Regard's
MVS

[noteirak]

Then that VMDK is not bootable and cannot be used, as suggested before. There is no way around this - if there is no boot information, there isn't. Use the whole chain or the root disk.

[MVS]

Thank you so much for your immediate response,

what is the procedure to use the whole chain of VMDK File ? As per our understanding in case of VHD File., we need to attach every VHD in the chain from FULL vhd and remove it and attach the next incremental in the chain and remove it, and so on till we reach the desired incremental to be attached and booted up. But in case of VMDK, we are pretty much unsure on what does attaching the whole chain of VMDK means ? Can you suggest any procedure on attaching the entire chain of VMDK file to the VBox.

Regard's
MVS

[noteirak]

I have split this part of your old topic into a new topic, as it make more sense is not related to the API anymore.

For the details on how to use VMDK, I don't have more info than what I posted. I never use this format so I cannot tell more.
But one thing is not clear to me : how many VMDK files do you have right now, for a given disk? More than one? One per snapshot yes?

[mpack]

You generally can't easily use "foreign" differencing chains in VirtualBox. That same statement would apply to your claim that you can use single differencing VHDs from some backup - I'd like to get details on that, but basically it can only have work if the entire chain is already represented somewhere in the media registered across different VMs.

There are however a couple of tricks you can use to merge foreign difference chains into a single VDI, e.g. using CloneVDI, or by registering all the media in a dummy VM and then cloning the last member of the chain.

ps. This kind of heavy use of differencing is just begging for a catastrophe. The whole point of a backup is to create redundancy in order to allow the correction of faults (you may not realise that's what you're doing, but it's true). The less redundancy you have, the less useful the backup is.

[ChipMcK]

regarding SnapShots

Code: Select all

When a virtual disk is first created for a new virtual machine, it is considered as the base disk for the guest - data for the guest is read from and written to that disk image.

The differencing disk records changes sector-by-sector to the whole disk image, not changes to any file in the disk. VirtualBox does not know what file system is employed on the disk image and therefore can not access any individual file of/on the disk image; only the guest OS is aware of that information.

First SnapShot creates a differencing disk (diffDisk#1) for read/write access while the base disk becomes read-only - as the guest modifies its data, the data is written to the differencing disk and the base disk is untouched.

Second SnapShot creates another, new, differencing disk (diffDisk#2) for read/write access while the first differencing disk (diffDisk#1) becomes read-only along with the base disk.

Subsequent SnapShots create additional differencing disks, with the preceding differencing disk joining the hierarchy (pecking order/chain) of read-only disks.

Keep in mind that access to/from the virtual disks is sector-by-sector, not file-by-file.

When the guest requests that a sector be read, the latest SnapShot is read first. If the sector is not found there (Sector-Not-Found is returned), the next SnapShot in the chain (youngest to oldest) is read, until the base virtual disk is reached. Then the sector is either read or Sector-Not-Found is returned.