Description of problem: I just tried virt-sparsify for the first time like so: mkdir /huge/tmp export TMPDIR=/huge/tmp virt-sparsify centinil.qcow2 centinil-base.qcow2 The process seemed to complete successfully, the new image is lots smaller, but the brand new /huge/tmp directory has lots of cruft left in it: [root@zooty images]# ls -laR /huge/tmp /huge/tmp: total 12 drwxr-xr-x 3 root root 4096 Jun 21 10:49 . drwxrwxrwx 8 root root 4096 Jun 21 10:31 .. drwxr-xr-x 3 root root 4096 Jun 21 10:32 .guestfs-0 /huge/tmp/.guestfs-0: total 12 drwxr-xr-x 3 root root 4096 Jun 21 10:32 . drwxr-xr-x 3 root root 4096 Jun 21 10:49 .. drwxr-xr-x 2 root root 4096 Jun 21 10:32 appliance.d -rw-r--r-- 1 root root 0 Jun 21 10:32 lock /huge/tmp/.guestfs-0/appliance.d: total 464112 drwxr-xr-x 2 root root 4096 Jun 21 10:32 . drwxr-xr-x 3 root root 4096 Jun 21 10:32 .. -rw-r--r-- 1 root root 1725440 Jun 21 10:32 initrd -rwxr-xr-x 1 root root 5518328 Jun 21 10:32 kernel -rw-r--r-- 1 qemu qemu 4294967296 Jun 21 10:32 root It should really clean all that up when it is finished. Version-Release number of selected component (if applicable): libguestfs-tools-c-1.26.3-2.fc20.x86_64 How reproducible: I only tried it once, but it seems likely to happen every time. Steps to Reproduce: 1.see above 2. 3. Actual results: leftover junk in TMPDIR Expected results: TMPDIR cleaned up to original state Additional info: Hmmm... I just tried booting the new image, and it don't work. I guess that's a different bug though...
This is basically this problem: http://libguestfs.org/guestfs-faq.1.html#libguestfs-uses-too-much-disk-space We created the appliance in $TMPDIR, as expected by experienced libguestfs users, although probably not by everyone :-( Upstream there are a couple of changes to make things better: (1) You can use the --tmp option to specify the place used for the huge temporary file. (2) The new --in-place option (in >= 1.26) allows you to avoid the issue entirely, since it no longer requires huge temporary files. I would recommend trying: virt-sparsify --in-place disk.img NOTE: This will OVERWRITE disk.img as it sparsifies it. But it will be far faster and not require much temporary space.
That link says: "It is safe to delete this directory when you are not using libguestfs." I'm not clear on why it is left up to me to delete the directory. Seems like virt-sparsify could delete it as it is finishing up. I don't really trust --in-place enough to want to use it without first making a copy of the image, so I figured I might as well let virt-sparsify make the copy in temp. If --in-place is really faster and better, perhaps the two arg form of virt-sparsify should be changed to work something like this: virt-sparsify arg1 arg2 becomes cp arg1 arg2 virt-sparsify --in-place arg2 P.S. I didn't see any actual info request for the needinfo flag, so I'm clearing it :-).
(In reply to Tom Horsley from comment #2) > That link says: "It is safe to delete this directory when you are not using > libguestfs." > > I'm not clear on why it is left up to me to delete the directory. Seems like > virt-sparsify could delete it as it is finishing up. It's stored in a temporary directory (usually, except when you set $TMPDIR) so it would get deleted eventually by whatever it is that cleans /tmp and /var/tmp on your operating system. The reason we keep the cached appliance around is to avoid having to rebuild it every time, which takes some significant amount of time. Try doing: rm -rf /var/tmp/.guestfs-* time guestfish -a /dev/null run time guestfish -a /dev/null run You'll notice that the first run of guestfish is considerably slower than the second and subsequent runs, because it is rebuilding the cached appliance. > I don't really trust --in-place enough to want to use it without first > making a copy of the image, so I figured I might as well let virt-sparsify > make the copy in temp. > > If --in-place is really faster and better, perhaps the two arg form of > virt-sparsify should be changed to work something like this: > > virt-sparsify arg1 arg2 > > becomes > > cp arg1 arg2 > virt-sparsify --in-place arg2 Unfortunately it's not that simple (never is ...). The in-place method requires recent and evolving kernel and qemu support. It cannot sparsify certain filesystems until kernel support is added. For example, it cannot sparsify NTFS, because the required kernel and filesystem support has not been done upstream. Copying mode uses a different technique -- mounting and filling the unused parts of the filesystem with a big file full of zeroes and then deleting it -- and this results in better sparsification which works on every filesystem, at the cost of having to make a copy of the disk and using lots of temporary space.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is essentially fixed upstream, so closing.