These are the instructions for creating an end-user VM from scratch.

VM Configuration

Base OS Install

There is a bug in virtual box with IPv6 handling over a bridged network.  When the bug is present the top transfer speeds for IPv6 are around 18kb/s.  Since RHEL (and derivatives) prefer IPv6 when looking up hosts, it is not uncommon to get an IPv6 host address for updates.  To disable IPv6 on the guest add these lines to /etc/sysctl.conf

net.ipv6.conf.all.disable_ipv6 = 1
 net.ipv6.conf.default.disable_ipv6 = 1

 

Avalon Install

Demo Content

VM Image Prep

 

Adding the demo batch increased the size of the VM download from 3.2G to 7.4G.  Partially its because we've make derivatives and there's really new content on the VM.  But for a bigger reason, any disk space that gets allocated is stored in the image file – the VM doesn't know what's being used and what isn't.  Since we download a largish package, untar it, and create a bunch of temp files, the VM disk image has a bunch of unused (from the OS point of view) disk that it still has to keep track of.  Future research should include how to 'unuse' the disk space.

"zerofree" should do the trick, when combined with vboxmanager modifyhd <name> --compact

Cleaning Unused Disk Space

VirtualBox's VBoxManager tool supports a compact option when modifying hard drives.  Unfortunately it only supports VDI so I'm experimenting with using VDI instead of VMDK for the disk container format.   For the purposes of the release, there should be no functional difference, except that VDI is less efficient than VMDK (on the Base OS install the VDI is 6% larger).

After a BaseOS install (as described above), the VDI disk image takes 4,304M of space.  A df on the system shows that 3405M is used for data, so there is nearly 1G of space which is a combination of filesystem overhead, VM sparse disk overhead, and non-zero-unused data. 

The first step is to see if the filesystem can be compacted using

VBoxManage modifyhd --compact avalon-vm-base-130419b.vdi

After a few minutes it comes back and shows that 4303M is being used – we saved 1M by running it.  I'm not impressed.

I know that I downloaded about 200M worth of update packages.  If the filesystem writes to the same places on the disk as it did before, a big dd should change that unused data to zeros:

dd if=/dev/zero of=/tmp/foo bs=10M count=1024; rm /tmp/foo

Afterward, the container was 4313M so the container grew by 10M – after writing 10G of zeros.  One would assume that the original deleted data is now zeros and the extra size is overhead of mapping a bunch of empty blocks.

Compacting it gives us a new disk size:  4077M – we've saved 400M by writing a big bunch of zeros.  Hooray!

I've written 4G of data to the image and it is currently 8176M on disk, even after erasing the files from the filesystem.

I've written 8G of zeros to the disk