Red Hat Bugzilla – Bug 734120
[RFE] use virt-sparsify to reduce image size
Last modified: 2016-07-04 05:29:34 EDT
Description of problem:
VDSM should use zerofree to reduce the image size before cloning disks and (probably) collapsing disks.
(In reply to comment #0)
> Description of problem:
> VDSM should use zerofree to reduce the image size before cloning disks and
> (probably) collapsing disks.
I would recommend using virt-sparsify instead or in addition ...
Zerofree really needs to be properly supported by our filesystem
team before we can start using it with customers. That's the
reason why it's not in RHEL at the moment. There is large scope
for it to do very bad things to customer data.
Also virt-sparsify, although it's much less efficient than
zerofree, has the advantage that it works with any type of
filesystem. In particular with NTFS, so it can sparsify Windows
guests, which obviously zerofree (being ext2/3-based) cannot.
I'm planning to put virt-sparsify in RHEL 6.3.
Rich - any updated thinking/status on this?
The current status is that virt-sparsify (the "copying" version
of it) is in RHEL 6.4, RHEL 7 and Fedora everything.
In future we want to have a version of virt-sparsify which
works in-place. This is something that might happen in RHEL 7.1.
It requires changes to qemu, kernel and more, see:
(In reply to comment #4)
Grrr, this link doesn't work unless you manually add a '-' to the
end of it ...
thoughts on impact vs. effort?
After a while of usage probably >10% possibly >50% (i.e. cut usage down by half!).
Effort - since this is a cold process and it starts by copying all the data from source to target then in our case the flow would be:
1. create a target disk
2. virt-sparsify (in case of error, delete target)
3. if all went well, the rest depends on the use case.
there are several use cases:
A. Attach to VM and detach original disk (copy all vm-disk properties) - to allow user to test the new disk. User would have to manually delete the old disk. Need to make sure they cannot be attached concurrently to avoid conflicts.
B. Make the disk into a template (no point in copying again) - i.e. virt-sparsify would be a checkbox when creating template
C. Keep as floating disk to be used with another VM (i.e. virt-sparsify would be a checkbox in clone disk operation or something).
Probably a lot more.
Effort depends on which use cases we would like to implement. The one for same VM is probably the most complex due to the logic around the existing copy vs. new one.
(In reply to Ayal Baron from comment #7)
> Effort - since this is a cold process and it starts by copying all the data
> from source to target
It depends on the backing store being used, but starting with RHEL 7
it should be possible to make virt-sparsify work entirely in-place.
(Note that no one's actually done that: virt-sparsify in RHEL 7.0
still works by copying ... just saying it's possible).
Adding Pino Toscano to CC as he is working on libguestfs things.
(In reply to Richard W.M. Jones from comment #8)
> (In reply to Ayal Baron from comment #7)
> > Effort - since this is a cold process and it starts by copying all the data
> > from source to target
> It depends on the backing store being used, but starting with RHEL 7
> it should be possible to make virt-sparsify work entirely in-place.
> (Note that no one's actually done that: virt-sparsify in RHEL 7.0
> still works by copying ... just saying it's possible).
Not sure we'd want to do this considering the scope of changes and the risk of loosing data...
However, it would be nice to split this out of virt-sparsify to allow doing more clever things (e.g. instead of full copy, use storage based snapshot which would be instantaneous and would not take up much space).
> Adding Pino Toscano to CC as he is working on libguestfs things.
The current patches, both those merges in VDSM and those not yet merged in the engine assume an SPM.
It would be a shame to invest work in doing something that will have to be re-written in a couple of weeks/months.
Let's wait till we have a proper SPM-less solution and then move on.
We want to continue development, but due to RHEL 7.3 dependency to make it useful I'm postponing this to 4.1.
Shahar, also note the need to properly lock the whole chain while the operation is in progress
we're going with virt-sparsify only, majority of remaining work is on engine side