similar to: Any risk in sparsifying a base image (that has a snapshot on top of it)

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

[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 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

As the minimum block size to discard in qcow2 is 64K, any point in fstrimming smaller contiguous blocks? TIA, Y.

$ 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

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

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 Sun, Dec 24, 2017 at 3:49 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Sun, Dec 24, 2017 at 02:15:44PM +0200, Yaniv Kaul wrote: > > I'm copying a file into a VM using virt-copy-in - which is great, but the > > file is wrongly labeled. > > How can I fix that? > > Hi Yaniv, > > The easiest thing is to run this after doing the virt-copy-in:

On Thu, Nov 23, 2017 at 10:57 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Tue, Nov 21, 2017 at 11:43:54PM +0200, Yaniv Kaul wrote: > > Since I upgrading to FC27, I *sometimes* fail to virt-sysprep. > > The debug messages: > > libguestfs: trace: set_verbose true > > libguestfs: trace: set_verbose = 0 > > libguestfs: create: flags = 0, handle =

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

Fix for https://bugzilla.redhat.com/show_bug.cgi?id=1364347

I'm copying a file into a VM using virt-copy-in - which is great, but the file is wrongly labeled. How can I fix that? TIA, Y.

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

Here's a fun one: + guestfish -N test-virt-sparsify-in-place-fstrim-unsupported.img=fs:vfat exit + virt-sparsify --in-place test-virt-sparsify-in-place-fstrim-unsupported.img + tee test-virt-sparsify-in-place-fstrim-unsupported.log [ 2.4] Trimming /dev/sda1 [ 7.5] Sparsify in-place operation completed with no errors + grep 'warning:.*fstrim'

zerofree is a package that can take an ext2 (only?) filesystem, work out what parts of the filesystem are not used, and either zero them or sparsify them. This was useful in about 2009 when I added it to Fedora. However nowadays it's more convenient to use the equivalent kernel functionality (via the ‘fstrim’ command or equivalent ioctls). The kernel functionality also works correctly for

On Wed, Sep 05, 2018 at 04:41:01PM +0100, Daniel P. Berrangé wrote: > On Wed, Sep 05, 2018 at 04:37:05PM +0100, Richard W.M. Jones wrote: > > > > Here's a fun one: > > > > + guestfish -N test-virt-sparsify-in-place-fstrim-unsupported.img=fs:vfat exit > > + virt-sparsify --in-place test-virt-sparsify-in-place-fstrim-unsupported.img > > + tee

On Thu, Nov 23, 2017 at 4:05 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Thu, Nov 23, 2017 at 03:00:45PM +0200, Yaniv Kaul wrote: > > On Thu, Nov 23, 2017 at 10:57 AM, Richard W.M. Jones <rjones@redhat.com> > > wrote: > > > > > On Tue, Nov 21, 2017 at 11:43:54PM +0200, Yaniv Kaul wrote: > > > > Since I upgrading to FC27, I

On Thu, Nov 23, 2017 at 02:05:32PM +0000, Richard W.M. Jones wrote: > On Thu, Nov 23, 2017 at 03:00:45PM +0200, Yaniv Kaul wrote: > > On Thu, Nov 23, 2017 at 10:57 AM, Richard W.M. Jones <rjones@redhat.com> > > wrote: > > > > > On Tue, Nov 21, 2017 at 11:43:54PM +0200, Yaniv Kaul wrote: > > > > Since I upgrading to FC27, I *sometimes* fail to

On Tue, May 17, 2016 at 05:53:31PM +0300, Yaniv Kaul wrote: > On Tue, May 17, 2016 at 5:48 PM, Richard W.M. Jones <rjones@redhat.com> > wrote: > > > On Tue, May 17, 2016 at 03:41:53PM +0100, Richard W.M. Jones wrote: > > > On Tue, May 17, 2016 at 05:15:57PM +0300, Yaniv Kaul wrote: > > > > When creating qcow2 images using virt-builder, is there a way to

On Tue, May 17, 2016 at 03:41:53PM +0100, Richard W.M. Jones wrote: > On Tue, May 17, 2016 at 05:15:57PM +0300, Yaniv Kaul wrote: > > When creating qcow2 images using virt-builder, is there a way to specify > > the qcow2 preallocation, as possible with qemu-img create -o > > preallocation=metada , for example? > > No .. but .. it does default to preallocation=metadata