[Libguestfs] Any risk in sparsifying a base image (that has a snapshot on top of it)

[Richard W.M. Jones]

On Tue, Nov 24, 2015 at 02:30:42PM +0200, Yaniv Kaul wrote:
> Assuming the VM is not running, and we have a base (raw, sparse) with a
> snapshot (qcow2) on top of it.
> Is there any issue with running virt-sparsify on the base image? I assume
> deleted blocks in the base can be sparsified, since they are either still
> deleted on the snap (which is fine) or were written in the snap (which is
> fine either and does not change or matter for the base image).

It could fail very badly (corrupting data), in at least the following
situation:

 - Base image has Linux filesystems that require journal recovery
   (eg. they were not unmounted, the VM was not shut down cleanly, or
   they represent a snapshot of a running system)

 - virt-sparsify --inplace will do:

    for each fs:
        mount fs /sysroot
        fstrim /sysroot

 - The mount command will replace the journal, making arbitrary
   changes to the base image.

 - The snapshot will not know about these changes, resulting in disk
   corruption when you try to access the VM via the snapshot.

virt-sparsify copying mode would do something similar.

There may be other situations where it could fail.  Definitely don't do it :-)

> Can I assume sparsifying should not make any changes that matter for a VM
> that will be spun (post the process)?

spun?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top