I use kvm/qemu on Linux and usual setup is having backing image and running top image that tracks changes (qemu-img create -f qcow2 -F qcow2 -b backimage topimage). I'm concerned with growth of those top images. I'd like to be able to do something similar to how I see COW on linux: see contents of top layer as ordinary directory tree, do scan, identify large folders/locations and just delete some if I don't consider those changes important enough (which in effect revert contents to lower level image; deleting deletions restores files on resulting fs). How to do similar for top layer image file in qemu-kvm? Could not find the answer via web search. TIA I've tried rebasing top on empty (just created by qemu-img) image, but then trying mounting as in e.g https://unix.stackexchange.com/questions/268460/how-to-mount-qcow2-image (guestmount, qemu-nbd) shows only whole disk with unknown filesystem (no partitions).

Is possible to resize a qemu/libvirt image maintaining virtual size and at same time don't loss data? I explain better: when you create a virtual disk qemu-img create -f qcow2 debian-GEN.qcow2 60G The virtual machine see a disk of 60G, but the space used is the space which the vm has used (this example is after installing some software) qemu-img info debian-GEN.qcow2 image: debian-GEN.qcow2 file format: qcow2 virtual size: 60 GiB (64424509440 bytes) disk size: 3.1 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: debian-GEN.qcow2 protocol type: file file length: 4.61 GiB (4948164608 bytes) disk size: 3.1 GiB Now the problem. Suppose I wrote 20GB of additional data, the disk size became 23GB (3.1+20), suppose then I remove 20GB of data (with rm -fr or even shred), the disk size is still 23GB! My question is this: there is a way to remove the 20GB of unused data from the virtual disk? So the image return 3.1GB (but the vm still see the 60GB space)?

We can use the -c option for qemu-img to compress the qcow2 file, e.g., here , but at the cost of uncompressing it while using. Suppose I am given a compressed qcow2 file, does qemu-img have any option or command to uncompress this qcow2 file? Thanks.

I've been trying to write a QCOW2 image to an iSCSI LUN target but have been unsuccessful. Based on this link, this should be possible (and should be possible without having to mount the iSCSI LUN as a disk) but from what error I am getting back, it's unclear to me whether what I am trying to do simply can't be done or I have a syntax error in the URL. The OS is Debian (Proxmox). Based on this output, the LUN should be visible: root@delta-vm:~# pvesm list TrueNAS Volid Format Type Size VMID TrueNAS:0.0.0.scsi-36589cfc000000f18d78a50cff1dec18b raw images 48318386176 root@delta-vm:~# ls /dev/disk/by-path/ ip-10.0.50.1:3260-iscsi-iqn.2005-10.org.freenas.ctl:delta-proxmox-target-lun-0 pci-0000:00:1f.2-ata-5.0-part1 pci-0000:00:1f.2-ata-5-part2 ip-10.0.60.1:3260-iscsi-iqn.2005-10.org.freenas.ctl:delta-proxmox-target-lun-0 pci-0000:00:1f.2-ata-5.0-part2 pci-0000:00:1f.2-ata-5-part3 pci-0000:00:1f.2-ata-5 pci-0000:00:1f.2-ata-5.0-part3 pci-0000:00:1f.2-ata-6 pci-0000:00:1f.2-ata-5.0 But when I try this, I am confused by the error message root@delta-vm:~# qemu-img convert -O raw /var/lib/vz/template/iso/Rocky-9-GenericCloud-Base.latest.x86_64.qcow2.img iscsi://10.0.50.1:3260/iscs-iqn.2005-10.org.freenas.ct l/delta-proxmox-target-lun-0 qemu-img: iscsi://10.0.50.1:3260/iscsi-iqn.2005-10.org.freenas.ctl/delta-proxmox-target-lun-0: error while converting raw: Protocol driver 'iscsi' does not support image creation, and opening the image failed: Failed to parse URL : iscsi://10.0.50.1:3260/iscsi-iqn.2005-10.org.freenas.ctl/delta-proxmox-target-lun-0 I have tried a few permutations of the URL above, but nothing seems to be working. E.g. cutting out the iscsi- string in URL doesn't help (the iSCSI Global Config is iqn.2005-10.org.freenas.ctl): root@delta-vm:~# qemu-img convert -O raw /var/lib/vz/template/iso/Rocky-9-GenericCloud-Base.latest.x86_64.qcow2.img iscsi://10.0.50.1:3260/iqn.2005-10.org.freenas.ctl/del ta-proxmox-target-lun-0 qemu-img: iscsi://10.0.50.1:3260/iqn.2005-10.org.freenas.ctl/delta-proxmox-target-lun-0: error while converting raw: Protocol driver 'iscsi' does not support image creation, and opening the image failed: Failed to parse URL : iscsi://10.0.50.1:3260/iqn.2005-10.org.freenas.ctl/delta-proxmox-target-lun-0 Any clues what am I doing wrong? The iSCSI portal(s) are unauthenticated so I am providing no user/pass combination to the URL above. For full disclosure (and I ack that this is tangential to my question), my ultimate goal with these gyrations would be to see if it's possible to re-target a disk (i.e. move storage) in qemu from local storage to iSCSI LUN but for some reason, this was never properly implemented in Proxmox so I have to take the scenic route. In other words, given this... root@delta-vm:~# qm config 105 agent: 1 ... onboot: 1 scsi0: samsung:vm-105-disk-0,discard=on,iothread=1,replicate=0,size=12G,ssd=1 scsihw: virtio-scsi-single .... ...I'd like to substitute the scsi0 device with the iSCSI LUN. From what I gather , this currently isn't possible as the code to materialise the disk image onto the LUN simply doesn't exist and an error is thrown (storage migration failed: can't allocate space in iscsi storage). EDIT: Some progress - specifying the _size_ argument to the directive changes the error. It looks like there is something definitely wrong with the URL root@delta-vm:~# qemu-img convert -O raw /var/lib/vz/template/iso/Rocky-9-GenericCloud-Base.latest.x86_64.qcow2.img iscsi://10.0.50.1:3260/iscsi-iqn.2005-10.org.freenas.ctl/delta-proxmox-target-lun-0 10G qemu-img: Could not open 'iscsi://10.0.50.1:3260/iscsi-iqn.2005-10.org.freenas.ctl/delta-proxmox-target-lun-0': Failed to parse URL : iscsi://10.0.50.1:3260/iscsi-iqn.2005-10.org.freenas.ctl/delta-proxmox-target-lun-0

My qemu version is QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-2+b1). I created a FreeBSD 14 VM using virt-manager. It's drive is a qcow2 image:

-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 8.1G 20240916 20:26:09.201 bsdie.qcow2

I am a member of the appropriate group:

groups
localuser cdrom floppy sudo audio dip video plugdev kvm netdev bluetooth scanner lpadmin libvirt libvirt-qemu

However, I get a permissions error when trying to run this machine using CLI:

qemu-system-x86_64 -cpu host -enable-kvm -m 1G -drive file=bsdie.qcow2  -net nic,vlan=0,macaddr=52:54:00:81:b6:cc -net user 
qemu-system-x86_64: -drive file=bsdie.qcow2: Could not open 'bsdie.qcow2': Permission denied

What am I missing? More generally, I'd like to know if there is a way of running machines defined via virt-manager using Qemu cmd. line; since the XML config files can be found in /etc/libvirt/qemu, I'd like to know if there is a way of "translating" the XML parameters into Qemu command-line args. Thanks!

I only have VirtualBox. I have a .qcow2 image I need to use. VirtualBox supports several file formats, but not .qcow2 What are my options? I'd much prefer not have to change to a different hypervisor.

Qcow 2 files are an open source file format for virtual machines. In my opinion, unlike .vmdk files, they do not offer the option of specifying a maximum file size. This means that they can constantly grow in size for various reasons. What ways are there to limit the growth of the file size of .qcow2 files when used under Debian 12 derivatives such as LMDE6 to a certain value or to be able to achieve a fixed file size? Perhaps they are better ideas, than to use a own partition for every .qcow file. One alternate idea can be possible, to use a file system for storing the .qcow file, which offer to set a quota by folder or by file for the file system, which are used to store the .qcow files. But that's are only ideas on this moment.

As far as I know, it is recommended to disable copy on write for VM images to avoid performance degradation on BTRFS. However, no one recommends against using qcow2 disk image format, despite being a copy on write disk. What is the reason behind this? What are the technical differences between BTRFS's CoW and qcow2 CoW?

I executed the following commands

-- 12:18:40 sudo virsh snapshot-delete Windows-10-128GB 2022-04-12-Pre-Activation
Domain snapshot 2022-04-12-Pre-Activation deleted
                                                                                                                                                                                                                                                  66ms

-- 12:28:20 sudo virsh snapshot-list Windows-10-128GB
 Name                         Creation Time               State
-------------------------------------------------------------------
 2022-04-12-Post-Activation   2022-04-12 21:54:19 +0200   shutoff
                                                                                                                                                                                                                                                  58ms


-- 12:28:24 qemu-img snapshot -l ~/kvm-images/Windows-10-128GB.qcow2
Snapshot list:
ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
1         2022-04-12-Pre-Activation      0 B 2022-04-12 21:19:39 00:00:00.000
2         2022-04-12-Post-Activation      0 B 2022-04-12 21:54:19 00:00:00.000

which lead me to believe that virsh snapshot-delete only removes the snapshots from libvirt's internal datastore without affecting the qcow2 file. So I deleted both this way and removed the VM from libvirt via sudo virsh undefine Windows-10-128GB. Before doing all this I exported the xml definitions of the snapshots and the VM:

sudo virsh dumpxml Windows-10-128GB > 2023-09-10---Windows-10-128GB.xml
sudo virsh snapshot-dumpxml Windows-10-128GB 2022-04-12-Pre-Activation > 2023-09-10---Windows-10--128GB---2022-04-12-Pre-Activation.xml
sudo virsh snapshot-dumpxml Windows-10-128GB 2022-04-12-Post-Activation > 2023-09-10---Windows-10-128GB---2022-04-12-Post-Activation.xml

But now when I re-issue qemu-img snapshot -l ~/kvm-images/Windows-10-128GB.qcow2, it no longer shows snapshots in that file. Also, the size decreased from

48G -rw-------  1 user user 156G Sep 10 12:52 Windows-10-128GB.qcow2
to
31G -rw-------  1 user user 156G Sep 10 12:52 Windows-10-128GB.qcow2

which seems to indicate that the snapshots are lost. Why didn't virsh snapshot-delete initially not delete the data from the qcow2 file, and, for future reference, how do I just remove a snapshot from libvirt but retain it in the qcow2 file, so that I can virsh undefine the VM and move the unused qcow2 file to some cold storage? virsh undefine Windows-10-128GB throwing the following was what moved me to remove the snapshots in the first place.

error: Failed to undefine domain 'Windows-10-128GB'
error: Requested operation is not valid: cannot delete inactive domain with 2 snapshots

I should add that the source paths to the qcow2 file in the snapshot-dumpxml were pointing to a non-existing file, because I once moved the file and adapted the xml of the VM to point to the new location. Could this be the reason why the snapshot didn't get removed in the first place? Because after that, I corrected the exported snapshot-dumpxml to point to the correct location and the used sudo virsh snapshot-create --redefine Windows-10-128GB 2023-09-10---Windows-10-128GB---2022-04-12-Pre-Activation---corrected.xml to re-integrate the snapshot into libvirt. Maybe these corrections then enabled virsh to remove it from the qcow2 file?

I have a qemu image B.qcow2 that is a snapshot of A.qcow2. I created a copy of B.qcow2 by using cp B.qcow2 C.qcow2 and then worked on both B.qcow2 and C.qcow2 independently. Thus, B.qcow2 and C.qcow2 are eventually different but they have a common part (since C.qcow2 was copied from B.qcow2). In order to save disk place, I wanted to know if it is possible (by using qemu-img or programmatically) to create another image common.qcow2 that will contain all common parts of B.qcow2 and C.qcow2, then remove this common part from B.qcow2 and C.qcow2 and rebase the images in such a way that B.qcow2 and C.qcow2 are based on common.qcow2 and common.qcow2 are based on A.qcow2?

In QEMU 5.1 zstd compression of your qcow2 files was introduced. But it's not described in the manual for qemu-img. How do you enable it?

I'm trying to understand how the write happens with a VM. It looks like running one is not blocked while copying it for a backup. Will the copy contain any modified files like the boot log? Or will it just copy from a 'shadow copy' like on Windows? The reverse question could be asked, as in, what happens if I start copying while a VM is open. I would guess the mechanics are similar. Would it change the copied file if changes are made during the copy process? My current guess is that only if files are changed that havent been copied yet. I've tested a VM copied this way and it had no noticeable brokenness, but I can image if a file is changed that relies on another file that is already copied to be different to operate, then it could break things. So corollary question is, are there files such as this that change during while the VM is running but not being actively used? I might assume running apt upgrade would be a bad idea, but I'm wondering if I can make a backup with little to no risk, while the VM is just open and running idle. I'm using virt-manager, but I would guess the answers depend more on the image file type qcow2 versus raw more than the VM host software. I'm also wondering if qcow2 has advantages or disadvantages versus a raw image in this regard.

I'm trying to reduce the usage of a qcow2 image. I did the following: qemu-img convert -p -f qcow2 -O qcow2 my_img.qcow2.backup my_img.qcow2 I outputs 200192 bytes and progress is stuck at 0.00%. CPU usage is pegged at 100% and I let it go for 2 hours. The input image file is 160G. Also, iotop says that there's no disk usage. What could qemu-img possibly be doing that's wasting this much time? Also, I should mention, I've tried using raw output format and it does the same thing.

I am using a macOS 12.2.1 with m1 chip. I successfully installed qemu using brew. I am trying to convert my ubuntu iso file to qcow2. When I run, >qemu-img create -f qcow2 ubuntu-20.04.3-live-server-arm64.iso 20G I get the output, >Formatting 'ubuntu-20.04.3-live-server-arm64.iso', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=21474836480 lazy_refcounts=off refcount_bits=16 which is pretty right, I guess, but it doesn't create the qcow2 file, cause when I run 'ls' it gives >ubuntu-20.04.3-live-server-arm64.iso What have I done wrong? Please help.

I'm running Apache on a VM with a qcow2 disk. Apache runs a (compiled C++) program which does the following: 1. It calls system to run another (C++) program which creates a file 2. It then attempts to read and process that file Step (2) attempts to open the new file with ifstream::open. When I run this program on the VM, this fails (ifstream::good returns false), with errno saying that the file doesn't exist. However, the file does actually exist if I open a shell and look for it. This program works fine when it's not on qcow2 (on 3 different RedHat and Ubuntu computers), which I'm guessing is implicated. I can fix this in two ways: 1. If I add another step between (1) and (2), and call `system("ls /foo/bar/myfile") the ls` command fails, returning 2. I can call it 100 times and it still fails. However, step (2) will now succeed 2. If I run system("sync") instead of system("ls"), step (2) succeeds Any idea what's going on? Does qcow2 have some unusual flush requirements? **Edit - added some sys info:** - RHEL 8.5, up-to-date - kernel 4.18.0-348.12.2.el8_5.x86_64 - emulating pc-q35-rhel8.2.0 - VM has 4GiB RAM, 2vCPUs (Skylake-Client-IBRS) - disk: 10GB, 35% used, virtio, default cache, Ubuntu 20.04 image I've run this setup for years with Win 7 and Linux images and never seen an issue before. $ virsh version Compiled against library: libvirt 6.0.0 Using library: libvirt 6.0.0 Using API: QEMU 6.0.0 Running hypervisor: QEMU 4.2.0

I use GNOME Boxes on Fedora 32 to virtualize a Fedora Silverblue installation. I did not setup a sophisticated/smart partitioning for my virtual Fedora and have run out of disk space on my virtual root partition. My objective is to be able to continue using my virtual Fedora machine as efficient and soon as possible without recreating the virtualization and without adding another partition. Therefore, how can I increase the root partition of my QEMU-based virtualization? Similar question: https://unix.stackexchange.com/questions/349586/resize-qcow2-root-parition

I want to install Ubuntu (or any distro) as UEFI with QEMU/libvirt and make some changes there at runtime and shut down the machine. This will create a qcow2 disk. If this was not a virtual machine and in the previous step I installed Ubuntu on a real PC instead, I could use a live USB to get access to the hard disk of the PC and do a byte copy of the entire disk. This would leave me with a raw image I could mount on a loopback device or pass it to tools which expect a raw image. Is there are way to access that kind of raw image directly from qcow2 somehow?

I wanted to build another server based on an existing config, so I performed the following: [user@box ~]# virt-clone --original serverA-rhel8 --name serverB-rhel8 --auto-clone Allocating 'serverA-rhel8-1-clone.qcow2' | 200 GB 00:00:16 As you can see, cloning resulted in a new qcow2 file, however the name of that file is misleading (since it is actually serverB-rhel8). Is there a way to either configure the qcow2 name when issuing virt-clone, or renaming the new qcow2 file afterwards?

Is there any way that I can find out from hypervisor the version of OS that I am runing on a vm. The problem is that I have an upgrade procedure that shuts down a vm, replaces the qcow2 image and then start it again with the new image. I need to know from hypervisor if the version running is the correct one.

I want to install archlinux in UEFI mode so, I created image from virt-manager with size of 20GB. Then after booting into VM, I created 2 partition with fdisk named /dev/vda1 and /dev/vda2 with 512MB and what remained (19.5~GB) I changed the type of /dev/vda1 to EFI from fdisk and then formated it with mkfs.fat -F32 /dev/vda1 Then I formated the /dev/vda2 to ext4 using mkfs.ext4 /dev/vda2 and then I successfully installed arch on it. The output of du -h -d 0 / on guest gives 5.2GB. But the actual disk size of image on host is 20GB which is same as Virtual size sudo qemu-img info archlinux.qcow2 image: archlinux.qcow2 file format: qcow2 virtual size: 20 GiB (21474836480 bytes) disk size: 20 GiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false I also have windows 10 installed on qcow2 image and It only show 9.73 disk size as expected. I didn't create any extra esp partitions during windows installation as I installed it in bios mode and it boots with seabios sudo qemu-img info win10.qcow2 [sudo] password for root: image: win10.qcow2 file format: qcow2 virtual size: 100 GiB (107374182400 bytes) disk size: 9.73 GiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false So what am I doing wrong here ? How can create partitions on qcow2 image without reserving partition size on disk ?