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

qemu-img info 100/vm-100-disk-0.qcow2 image: 100/vm-100-disk-0.qcow2 file format: qcow2 virtual size: 120 GiB (128849018880 bytes) disk size: 916 GiB cluster_size: 65536 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false refcount bits: 16 corrupt: false extended l2: false Child node '/file': filename: 100/vm-100-disk-0.qcow2

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),

Hi there. I can't understand why I am having this different values: proxmox01:/vms/images# df Sist. Arq. Tam. Usado Disp. Uso% Montado em udev 252G 0 252G 0% /dev tmpfs 51G 9,4M 51G 1% /run /dev/sda4 433G 20G 413G 5% / tmpfs 252G 63M 252G 1% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock efivarfs 496K 335K

What's your gluster version ? Best Regards,Strahil Nikolov ? ??????????, 11 ??????? 2024 ?. ? 20:57:50 ?. ???????+2, Gilberto Ferreira <gilberto.nunes32 at gmail.com> ??????: Hi there. I can't understand why I am having? this different values: proxmox01:/vms/images# df Sist. Arq. ? ? ?Tam. Usado Disp. Uso% Montado em udev ? ? ? ? ? ?252G ? ? 0 ?252G ? 0% /dev tmpfs ? ? ?

11.1 --- Gilberto Nunes Ferreira +55 (47) 99676-7530 Proxmox VE VinChin Backup & Restore Em qua., 20 de nov. de 2024, 19:28, Strahil Nikolov <hunter86_bg at yahoo.com> escreveu: > What's your gluster version ? > > Best Regards, > Strahil Nikolov > > ? ??????????, 11 ??????? 2024 ?. ? 20:57:50 ?. ???????+2, Gilberto > Ferreira <gilberto.nunes32 at

Have you figured it out ? Have you tried setting storage.reserve to 0 ? Best Regards, Strahil Nikolov On Thu, Nov 21, 2024 at 0:39, Gilberto Ferreira<gilberto.nunes32 at gmail.com> wrote: 11.1 --- Gilberto Nunes Ferreira +55 (47) 99676-7530 Proxmox VE VinChin Backup & Restore Em qua., 20 de nov. de 2024, 19:28, Strahil Nikolov <hunter86_bg at yahoo.com> escreveu:

No! I didn't! I wasn't aware of this option. I will try. Thanks Em sex., 29 de nov. de 2024 ?s 16:43, Strahil Nikolov <hunter86_bg at yahoo.com> escreveu: > Have you figured it out ? > > Have you tried setting storage.reserve to 0 ? > > Best Regards, > Strahil Nikolov > > On Thu, Nov 21, 2024 at 0:39, Gilberto Ferreira > <gilberto.nunes32 at

[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

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

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

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