similar to: [PATCH] sparsify: skip test-virt-sparsify-in-place.sh if discard is not supported

Since Linux commit f663b5b38fff trimming vfat is now supported by Linux. This broke the test which assumed it was not supported. Use another filesystem (minix) which does not support trimming instead. Thanks: Daniel P. Berrangé and Pino Toscano. --- ...est-virt-sparsify-in-place-fstrim-unsupported.sh | 13 ++++++------- tests/test-functions.sh | 10 ++++++++++ 2

Since Linux commit f663b5b38fff trimming vfat is now supported by Linux. This broke the test which assumed it was not supported. Use another filesystem (minix) which does not support trimming instead. Thanks: Daniel P. Berrangé and Pino Toscano. --- ...virt-sparsify-in-place-fstrim-unsupported.sh | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git

$ qemu-img create -f qcow2 -b /tmp/centos-6.img overlay.qcow2 $ virt-sparsify --in-place overlay.qcow2 virt-sparsify: error: disk image 'overlay.qcow2' appears to have a backing file. You should use copying mode sparsification for this file (see the virt-sparsify(1) manual). Thanks: Yaniv Kaul --- sparsify/in_place.ml | 5 +++++ 1 file changed, 5 insertions(+) diff --git

On Wed, Nov 04, 2015 at 01:10:04PM +0200, Yaniv Kaul wrote: > On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <rjones@redhat.com> > wrote: > > All that happened was that the overlay got bigger (because it's now > > storing a bunch of qcow2 zero clusters marking the places in the > > backing file which are zero). ^^^ Here I should

On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > [Let's discuss this upstream] > > On Wed, Nov 04, 2015 at 12:18:48PM +0200, Yaniv Kaul wrote: > > I'm missing something here - what will happen to the tree structure? > > Will we lose it? So essentially it performs a merge? > > In copying mode: > > virt-sparsify disk1

This addresses the feedback on v1 here: https://www.redhat.com/archives/libguestfs/2018-September/msg00023.html Rich.

Just refactoring, no change. --- sparsify/cmdline.ml | 49 +++++++++++++++++++++++-------------------------- 1 file changed, 23 insertions(+), 26 deletions(-) diff --git a/sparsify/cmdline.ml b/sparsify/cmdline.ml index ce2b913..bd49e71 100644 --- a/sparsify/cmdline.ml +++ b/sparsify/cmdline.ml @@ -98,6 +98,7 @@ read the man page virt-sparsify(1). let check_tmpdir = !check_tmpdir in let

[Let's discuss this upstream] On Wed, Nov 04, 2015 at 12:18:48PM +0200, Yaniv Kaul wrote: > I'm missing something here - what will happen to the tree structure? > Will we lose it? So essentially it performs a merge? In copying mode: virt-sparsify disk1 disk2 creates an overlay on top of disk1, writes zeroes to the overlay in the parts of disk1 which are not used (disk1 is not

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

We could go a bit further here and push the cmdline struct into Copying.run and In_place.run. --- sparsify/Makefile.am | 5 ++++- sparsify/cmdline.ml | 23 +++++++++++++++++++---- sparsify/cmdline.mli | 36 ++++++++++++++++++++++++++++++++++++ sparsify/sparsify.ml | 13 +++++++------ 4 files changed, 66 insertions(+), 11 deletions(-) create mode 100644 sparsify/cmdline.mli diff --git

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

virt-sparsify shouldn't die if sparsifying a filesystem that contains read-only LVs. https://bugzilla.redhat.com/show_bug.cgi?id=1185561 I thought about trying to make the LV writable temporarily, but I suspect that if the sysadmin has made the LV read-only, then they probably did it for a reason, so we shouldn't touch it. Rich.

--- sparsify/copying.ml | 4 +++- sparsify/in_place.ml | 4 +++- sparsify/utils.ml | 16 ++++++++++++++++ 3 files changed, 22 insertions(+), 2 deletions(-) diff --git a/sparsify/copying.ml b/sparsify/copying.ml index 8d77964..165dd6e 100644 --- a/sparsify/copying.ml +++ b/sparsify/copying.ml @@ -216,9 +216,11 @@ You can ignore this warning or change it to a hard failure using the

Hi, On CentOS 8, when using virt-sparsify for a ntfs image, it does not seem to work. Tried virt-sparsify on Fedora 32 and it works great. Is there some dependent application that need to be installed in CentOS 8 for virt-sparsify to work on ntfs? Here are some information. CentOS 8. # virt-sparsify -V virt-sparsify 1.38.4rhel=8,release=14.module_el8.1.0+248+298dec18,libvirt #

On Wednesday 28 January 2015 14:25:38 Richard W.M. Jones wrote: > --- > sparsify/copying.ml | 4 +++- > sparsify/in_place.ml | 4 +++- > sparsify/utils.ml | 16 ++++++++++++++++ > 3 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/sparsify/copying.ml b/sparsify/copying.ml > index 8d77964..165dd6e 100644 > --- a/sparsify/copying.ml > +++

Hello, Thanks for all the information, I think my last remaining question is why the image created with virt-install shows the full apparent size and the image from virt-sparsify does not? (The image testimage1.qcow2 created with default options). As they are both qcow2 I would expect them both to have the same behavior as far as apparent size goes. Or is there an option I am missing in

Hi! This question emerged during testing of oVirt sparsify integration. oVirt now is able to run virt-sparsify on VM disks. But virt-sparsify seems to have no effect on iSCSI disks. Does virt-sparsify work on iSCSI disks? Maybe in sum situation, with some configuration of iSCSI server, with some specific virt-sparsify options? Shmuel

[I don't normally monitor this list for issues - it's better to send bugs to the libguestfs mailing list] On Tue, Aug 28, 2012 at 09:07:23PM +0100, Paul Maunders wrote: > I've found an issue with virt-sparsify on Centos 6.3 with it's image > format detection. If I take a qcow2 image and attempt to sparsify it > with... > > virt-sparsify -v centos6.3-gold.img

Use the common function for ensuring a path is absolute; it should not change the behaviour at all. --- sparsify/cmdline.ml | 6 +----- v2v/input_disk.ml | 4 +--- v2v/input_ova.ml | 4 +--- 3 files changed, 3 insertions(+), 11 deletions(-) diff --git a/sparsify/cmdline.ml b/sparsify/cmdline.ml index 3eb0d5b..523d612 100644 --- a/sparsify/cmdline.ml +++ b/sparsify/cmdline.ml @@ -142,11

With commit a594b7f90a682e2a9327b142138edb76ad8ba8ff the checks for input and output files with ':' were removed; while the input file is handled correctly by the disk_create API, an output filename with ':' could still be handled as specifying a transport, failing the last "qemu-img convert" call. Use the new qemu_input_filename helper to handle the output filename