similar to: Re: Fwd: [Bug 1277705] virt-sparsify --in-place should not sparsify a snapshot

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

$ 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, Jun 22, 2016 at 05:56:09PM -0500, libvirt_users@skagitattic.com wrote: > > Delete what you've done and start from the beginning. Describe > > exactly how you created the guest. Use 'qemu-img info' to show the > > format of the input file. Show precisely the virt-sparsify command > > you are running. And use 'qemu-img info' on the output file

On Wed, Jun 22, 2016 at 12:40:40AM -0500, libvirt_users@skagitattic.com wrote: > So you are saying when I do the virt-sparsify its converting the image > from raw to [qcow2]? No. virt-sparsify will use the same input and output formats, unless you use the --convert option. > I studied the man page for virt-sparsify and tried again with > the flag "--format raw"

Instead of creating Guestfs handles and manually apply common options (e.g. debug and trace), use the open_guestfs in Common_utils. This also applies the common options to handles which didn't set them before, so we can inspect also their messages if needed. --- builder/builder.ml | 8 ++------ customize/customize_main.ml | 4 +--- dib/dib.ml | 4 +---

On Thu, Jun 23, 2016 at 10:57:43AM -0500, libvirt_users@skagitattic.com wrote: > 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). I don't really know what you mean by "full

The first patch is just some simple refactoring. See the second patch for a description of the new virt-sparsify --tmp option. I tested this using a loopback device as my temporary block device, and it seems to work fine for me. Federico .. this needs a BZ :-) Rich.

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

In this mode, converting of the VM configuration, setting up the rollback path for error cases, transforming the VM storage and so on is taken care of by a third-party toolset, and virt-v2v is only supposed to tune up the guest OS directly inside the source VM, to enable it to boot and run under the input hypervisor. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> ---

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

Hello, I'm using virt-sparsify on a new server and I get an error message: # virt-sparsify img img2 [   0.0] Create overlay file in /tmp to protect source disk [   0.1] Examine source disk virt-sparsify: error: libguestfs error: guestfs_launch failed. This usually means the libguestfs appliance failed to start or crashed. Here is libguestfs-test-tool output:

Hello, I am curious why when using virt-sparsify the apparent-size of the file gets reduced to the actual file size? Is there a way to get the apparent-size left as the full size? In the man page for virt-sparsify it has a section on "IMPORTANT NOTE ABOUT SPARSE OUTPUT IMAGES" and its output seems to indicate what I would expect where "ls -lh" shows the full apparent size

Hello, I am curious why when using virt-sparsify the apparent-size of the file gets reduced to the actual file size? Is there a way to get the apparent-size left as the full size? In the man page for virt-sparsify it has a section on "IMPORTANT NOTE ABOUT SPARSE OUTPUT IMAGES" and its output seems to indicate what I would expect where "ls -lh" shows the full apparent size

> Your quoting is horrible. You used the same prefix for your original > content as for my reply (">> >" in both cases). I'm not sure what > mailer you are using, but it is making conversation difficult. OK, let's see if this is better. Turned out my email app wasn't doing text wrap and quoting prefix default was bizarre....my apologies. > > >

On Wed, Jun 15, 2016 at 10:20:54AM -0500, libvirt_users@skagitattic.com wrote: > Hello, > > I am curious why when using virt-sparsify the apparent-size of the file > gets reduced to the actual file size? Is there a way to get the > apparent-size left as the full size? > > In the man page for virt-sparsify it has a section on > "IMPORTANT NOTE ABOUT SPARSE OUTPUT

On Wed, Jun 15, 2016 at 10:20:54AM -0500, libvirt_users@skagitattic.com wrote: > Hello, > > I am curious why when using virt-sparsify the apparent-size of the file > gets reduced to the actual file size? Is there a way to get the > apparent-size left as the full size? > > In the man page for virt-sparsify it has a section on > "IMPORTANT NOTE ABOUT SPARSE OUTPUT

A lot of code runs 'qemu-img create' or 'truncate' to create blank disk images. In the past I resisted adding an API to do this, since it essentially duplicates what you can already do using other tools (ie. qemu-img). However this does simplify calling code quite a lot since qemu-img is somewhat error-prone to use (eg: don't try to create a disk called "foo:bar")

I use my "custom" TMPDIR variable with virt-sparsify. I just type: export -p TMPDIR=/mnt/vm/tmpdir I do that for a couple reasons: either my /tmp is on a ramdisk or /tmp is on my (ssd) rootfs and i dont want to "full" my / with the temporally files. Thats said, i was thinking to "ask" OR sending a patch for adding a tmpdir OPTION for virt-sparsify like

[Added Stefan Hajnoczi, who wrote the 'drive-backup' QMP command and Eric Blake.] On Wed, Mar 25, 2015 at 07:41:23PM +0000, Richard W.M. Jones wrote: > On Wed, Mar 25, 2015 at 07:38:03PM +0100, Kashyap Chamarthy wrote: > > On Mon, Mar 23, 2015 at 10:43:30PM +0000, Richard W.M. Jones wrote: [. . .] > > > > If you want lightweight, consistent, point-in-time snapshots