6:30 a.m.
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).
Can I assume sparsifying should not make any changes that matter for a VM
that will be spun (post the process)?
TIA,
Y.
7:40 a.m.
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
7:41 a.m.
On Tue, Nov 24, 2015 at 01:40:28PM +0000, Richard W.M. Jones wrote:
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.
s/replace/replay/
- 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
--
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
3100
days inactive
3100
days old
2 comments
2 participants
participants (2)
-
Richard W.M. Jones -
Yaniv Kaul