Can I convert VMDK->VDI, compact, convert back a ***CHILD*** VMDK?

[UTAN_dev]

(Ubuntu host, Ubuntu guest.) My dev environment is DrupalVM. It uses VMDKs, not VDIs. I have several dev VMs (one for each project) as a child VMDK of a common base VMDK.

One of my VMs filled up with tens of GB of garbage log entries. After deleting them, I need to compact the VM's virtual disk using the tutorial at https://vladimir-ivanov.net/how-to-comp ... file-size/ .

Here's the `showhdinfo` output:

Code: Select all

vboxmanage showhdinfo '/home/monkey/VirtualBox VMs/packer-ubuntu-16.04-amd64_1490228590884_50286/packer-ubuntu-16.04-amd64-disk1.vmdk'
UUID:           3da459f3-a35c-4d63-8198-1ca8d029fb91
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /home/monkey/VirtualBox VMs/packer-ubuntu-16.04-amd64_1490228590884_50286/packer-ubuntu-16.04-amd64-disk1.vmdk
Storage format: VMDK
Format variant: dynamic default
Capacity:       81920 MBytes
Size on disk:   1836 MBytes
Encryption:     disabled
In use by VMs:  packer-ubuntu-16.04-amd64_1490228590884_50286 (UUID: 8b49ecd5-239c-4143-a12b-803620d6850f) [base (UUID: be5f79ae-3680-4a68-9bc3-b936abd426d5)]
Child UUIDs:    bd86a93c-0ea6-45ee-8caa-e532927bedaa
                35717a4a-a575-4d5f-80c6-b7e7647a24f4
                57686342-0aa9-467f-9485-852b37d84b5b

My question: can you `clonehd` a VMDK to VDI, compact it, and convert it back if it's a child disk? (UUID 35..f4, in this case)

[mpack]

Child disk as in a snapshot or linked clone? No, that won't work. It wouldn't work even if it was VDI. Differential formats are inherently inflexible: no move offline, no compact (*), etc. Easy to mess up backups too. And risky: single point of mega-failure. Then you have the added loss of functionality from choosing the foreign VMDK format in a VirtualBox environment.

(*) Technically, compaction of a difference image is possible, simply pointless since most of the blocks of a differential disk are transients that will be added right back. In your case even this is impossible because there is no facility to clone a partial image to VDI or to compact a VMDK.

[UTAN_dev]

I just checked and DrupalVM uses linked clones.

On my kpuc VM, there's a "Current state" snapshot and hovering over the (only) disk in the Storage Tree displays:

Code: Select all

/home/monkey/VirtualBoxVMs/packer-ubuntu-16.04-amd64_1490228590884_50286/packer-ubuntu-16.04-amd64-diskl.vmdk
Type (Format): Normal (VMDK) 
Attached to: packer-ubuntu-16.04-amd64_1490228590884_50286 (base) 
This base hard disk is indirectly attached using the following differencing hard disk: 
/home/monkey/VirtualBox VMs/kpuc.drupalvm.dev/Snapshots/(35717a4a-a575-4d5f-80c6-b7e7647a2414).vmdk 
Type (Format): Differencing (VMDK) 
Attached to: kpuc.drupalvm.dev 

Is there any way at all to reduce the size of this VM?

[mpack]

Is there any way at all to reduce the size of this VM?

Yes, but it isn't reversible as requested in the topic title (though I don't know why you'd want to reverse it anyway).

The method: clone the child VM, choosing to clone the current state only, don't reset the MAC address. That should give you a stand alone (merged) VM based around a VDI. Now clone that VDI using CloneVDI (running under Wine), with the Compact, and "Keep UUID" options enabled. Remove the old VDI from the clone VM, replace with the compacted VDI.

Do not follow any advice that tells you to run zerofree prior to cloning the VM. That advice is useless when applied to linked clones.

At this point you can delete the old child VM, and the base VM too unless it's needed by other child VMs.


Moving this topic to "Linux Hosts" since the discussion is not generic "Using VirtualBox" territory.

Perhaps you might discuss why you believe that a heavily mutually interdependent VMDK linked structure is an advantage?

[UTAN_dev]

Perhaps you might discuss why you believe that a heavily mutually interdependent VMDK linked structure is an advantage?

It's not my decision; this environment is created by DrupalVM, a utility to generate Drupal dev environments. Those VMs are really meant to be ephemeral (DrupalVM's author regenerates and destroys VMs sometimes several times a day, after committing new code and moving onto another project), throwaway environments. My fault is keeping old VMs around.

Thanks for your help!