similar to: virt-sparsify changing the apparent-size of files

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"

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

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

Hello Rich, Thanks for the reply and information. > What is file.img? Its simply a file I made while testing sparse files "truncate -s 512M file.img". > 'du --apparent-size' and 'ls -l' are the same thing, so it's not > really surprising that you see the same numbers here. Indeed, I expected those to be the same, just figured I would show them both for

> 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 too. Okay, here goes. Start off with an install root@testingbox:~ # virt-install --name

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

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

Hello list, upon upgrading from libvirt v5.9.0 -> v5.10.0, libvirt started calling qemu differently causing the VM operating system to not be found. I'm wondering whether I'm chasing a bug, or have to otherwise fix my domain config (created by virt-manager). To start with, I have a Windows 7 domain based on the following images: windows7-base.qcow2: QEMU QCOW2 Image (v3),

[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

$ 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

I have been using internal snapshots on production qcow2 images for a couple of years, admittedly as infrequently as possible with one exception and that exception has had multiple snapshots taken and removed using virt-manager's GUI. I was unaware of this: > There are some technical downsides to > internal snapshots IIUC, such as inability to free the space used by the > internal

Hi all, experimenting with vol-create-as, I think it should autodetect some data - filesize and backing file format, specifically. However, the current implementation require us to specify both filesize and backing file format. Considering that qemu-img already autodetects these data, there are any reason for the lack of autodetect by libvirt? Should I open a bugzilla issue? Below you can

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

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

Hi,guys I wanna to get the disk snapshot size, but found nothing libvirt commands related,except qemu-img. I create two disk snapshots, but nothing return its' size [root@cskvm01 qcow2]# qemu-img info /mnt/e6758700-af68-3c06-ade3-53f5f9b93507/e2cf6551-0d2c-4382-a86c-8ba633954ff2 image: /mnt/e6758700-af68-3c06-ade3-53f5f9b93507/e2cf6551-0d2c-4382-a86c-8ba633954ff2 file format: qcow2 virtual

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.

Hi all, on a fully patched CentOS 7.4 x86-64, I see the following behavior: - when creating a new volumes using vol-create-as, the resulting file is a qcow2 version 2 (compat=0.10) file. Example: [root@gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img Vol zzz.qcow2 created [root@gdanti-lenovo vmimages]# file

----- Original Message ----- From: "Eric Blake" <eblake@redhat.com> To: "Adam King" <kinga@sghs.org.uk>, libvirt-users@redhat.com Sent: Thursday, August 21, 2014 3:17:09 AM Subject: Re: [libvirt-users] virsh snapshot On 08/20/2014 06:34 PM, Adam King wrote: > Hi, > [Can you convince your mailer to wrap long lines?] > > I had a 'domain' called

Hello All, I am using Centos 6.3 with libvirt 0.910 and qemu-kvm 0.12 I had to resize a qcow2 disk, and came across several issues; I used this command to resize the image: sudo -i /usr/bin/qemu-img /var/lib/libvirt/images/mydisk.img resize +100G . The disk is attached using virtio. I then tried to use parted from within the guest to resize the partition. The first problem was that the