Description of problem: At a stable 32 bit Gentoo linux with virt-manager 0.10 I created a virtual machine using an iso image from https://tails.boum.org/ as a CD-ROM. After the virtual machine was created I changed the format from "raw" to "qcow2" of the hard disk "IDE Disk 1" (unfortunately this step is necessary b/c during creation of the virtual machine I found no *working* way to directly specifying "qcow2") I'm wondering that the occupied space on hard disc is still 8 GB: -rw------- 1 root root 8589934592 Jan 25 11:33 /var/lib/libvirt/images/tails.img If I add another hard disk with "qcow2" then the size of the corresponding file is (as expected) much smaller : n22 ~ # ls -l /var/lib/libvirt/images/tails* -rw------- 1 root root 197120 Jan 26 10:53 /var/lib/libvirt/images/tails-1.img -rw------- 1 root root 8589934592 Jan 25 11:33 /var/lib/libvirt/images/tails.img Now I can remove the first hard disk and can save file system space. FWIW I'm pretty sure that the first created disk is still in format "raw" although "qcow2" is shown.
P.S. After creating the 2nd hard disc I can now remove the first and the result is as expected : n22 ~ # ls -l /var/lib/libvirt/images/* -rw------- 1 root root 197120 Jan 25 18:05 /var/lib/libvirt/images/minimal-1.img -rw------- 1 root root 197120 Jan 26 11:01 /var/lib/libvirt/images/minimal.img -rw------- 1 root root 197120 Jan 26 10:53 /var/lib/libvirt/images/tails-1.img -rw------- 1 root root 197120 Jan 26 11:00 /var/lib/libvirt/images/tails.img But I'm wondering why the files will be left on my hard disc when I remove the disc from the configuration.
(In reply to Toralf Förster from comment #0) > Description of problem: > > At a stable 32 bit Gentoo linux with virt-manager 0.10 I created a virtual > machine using an iso image from https://tails.boum.org/ as a CD-ROM. > After the virtual machine was created I changed the format from "raw" to > "qcow2" of the hard disk "IDE Disk 1" (unfortunately this step is necessary > b/c during creation of the virtual machine I found no *working* way to > directly specifying "qcow2") > On the storage page of the 'new vm' wizard, hit browse, select a qcow2 volume or create a new one, and virt-manager should do the correct thing. Works upstream at least. If however you pass a path that is not managed by a libvirt storage pool, virt-manager just assumes it as raw. There's a bug about fixing this (among other things): > > I'm wondering that the occupied space on hard disc is still 8 GB: > > -rw------- 1 root root 8589934592 Jan 25 11:33 > /var/lib/libvirt/images/tails.img > > > If I add another hard disk with "qcow2" then the size of the corresponding > file is (as expected) much smaller : > > n22 ~ # ls -l /var/lib/libvirt/images/tails* > -rw------- 1 root root 197120 Jan 26 10:53 > /var/lib/libvirt/images/tails-1.img > -rw------- 1 root root 8589934592 Jan 25 11:33 > /var/lib/libvirt/images/tails.img > > > Now I can remove the first hard disk and can save file system space. > > FWIW I'm pretty sure that the first created disk is still in format "raw" > although "qcow2" is shown. qemu-img info <file> should tell it. But not sure why one file is huge compared to another. (In reply to Toralf Förster from comment #1) > P.S. > After creating the 2nd hard disc I can now remove the first and the result > is as expected : > > n22 ~ # ls -l /var/lib/libvirt/images/* > -rw------- 1 root root 197120 Jan 25 18:05 > /var/lib/libvirt/images/minimal-1.img > -rw------- 1 root root 197120 Jan 26 11:01 > /var/lib/libvirt/images/minimal.img > -rw------- 1 root root 197120 Jan 26 10:53 > /var/lib/libvirt/images/tails-1.img > -rw------- 1 root root 197120 Jan 26 11:00 /var/lib/libvirt/images/tails.img > > But I'm wondering why the files will be left on my hard disc when I remove > the disc from the configuration. virt-manager needs to be extended to offer to remove the disk image when removing a disk device from a VM, it doesn't presently. a separate RFE would be welcome for that
(In reply to Cole Robinson from comment #2) > On the storage page of the 'new vm' wizard, hit browse, select a qcow2 > volume or create a new one, and virt-manager should do the correct thing. Here not. If I create a new vm, I can choose "Customize configuration before installation" - but for a disk (if specified to create them by virt-manager) I cannot change the format under "Advanced options" - the field "Storage format" is grayed out and "raw" is seen. If I however remove the disk (before I press "continue with the Installation") and attach a new disk, then I'm allowed to change the format and the created file is really in qow2 format : $ ls -l /var/lib/libvirt/images/test* -rw------- 1 qemu qemu 197120 Jan 26 19:26 /var/lib/libvirt/images/test.img > virt-manager needs to be extended to offer to remove the disk image when > removing a disk device from a VM, it doesn't presently. a separate RFE would > be welcome for that done
FWIW Python 2.7.5 is my active interpreter here at a x86 Gentoo.
(In reply to Toralf Förster from comment #3) > (In reply to Cole Robinson from comment #2) > > > On the storage page of the 'new vm' wizard, hit browse, select a qcow2 > > volume or create a new one, and virt-manager should do the correct thing. > > Here not. > If I create a new vm, I can choose "Customize configuration before > installation" - but for a disk (if specified to create them by virt-manager) > I cannot change the format under "Advanced options" - the field "Storage > format" is grayed out and "raw" is seen. > This is expected though I agree the UI is awkward. What that field changes is just what we tell qemu the format of the disk image is, not what format the disk image is _created_ as. To influence that, you need to select 'Browse' on the third page of the New VM wizard as mentioned above. That's why the field is disabled in the 'customize' page, to try and make it clear that it's not doing what you think it's going to do. Wiring that field up to the actual created disk image format sucks, because we have to go back and validate disk size and other things. We can add a warning icon next to the disabled format dropdown, with a tooltip explaining the situation. > If I however remove the disk (before I press "continue with the > Installation") and attach a new disk, then I'm allowed to change the format > and the created file is really in qow2 format : > > $ ls -l /var/lib/libvirt/images/test* > -rw------- 1 qemu qemu 197120 Jan 26 19:26 /var/lib/libvirt/images/test.img > > > > virt-manager needs to be extended to offer to remove the disk image when > > removing a disk device from a VM, it doesn't presently. a separate RFE would > > be welcome for that > > done Thanks!
(In reply to Cole Robinson from comment #2) > removing a disk device from a VM, it doesn't presently. a separate RFE would > be welcome for that #bug 1058051 :-)
Created attachment 855759 [details] screen shot of qcow2 (In reply to Cole Robinson from comment #5) To sum it up - I'm not able to create a VM with a qcow2 format currently. And creating it and later change the format doesn not change the format really. I did it (see the screen shot) , but qemu says : tfoerste@n22 /var/lib/libvirt/images $ sudo qemu-img info test.img image: test.img file format: raw virtual size: 8.0G (8589934592 bytes) disk size: 8.0G and next attachments shows the error from virt-manager, when I try to start the VM (however as soon as I change back from "qcow2" into "raw", the vm can be used again).
Created attachment 855760 [details] screen shot of the error msg
Can you try reproducing with virt-manager git? git clone git://git.fedorahosted.org/virt-manager.git cd virt-manager ./virt-manager --debug And if still hitting the issue, post the debug output here
Created attachment 856152 [details] /virt-manager --debug 1>~/tmp/virt-manager.log 2>&1 Pff, now it looks different, used tree : v0.10.0-697-gad363f9 Creating a new machine seems to set "qcow2" as a standard - that's good. But the created file is 8 GB in size ! Furthermore qemu-img reports somewhat different about the file size - and I do know, that with virt-manager 0.10.0 a 8 GB hard disk in qcow2 format just occupies 193 KB : tfoerste@n22 /var/lib/libvirt/images $ ls -lh * -rw------- 1 qemu qemu 193K Jan 26 11:01 minimal.img -rw------- 1 root root 193K Jan 26 11:00 tails.img -rw------- 1 qemu qemu 8.1G Jan 27 18:11 vm1.img tfoerste@n22 /var/lib/libvirt/images $ sudo qemu-img info vm1.img image: vm1.img file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 1.4M <------------------ ? cluster_size: 65536 (app-emulation/qemu-1.6.1 is used here with kernel 3.12.9)
virt-manager git defaults to qcow2, yes. It also defaults to doing qcow2 metadata preallocation: this is a performance improvement. However it does not fully allocate the disk. What you are seeing is the fact that ls -l does not correctly report the size of sparse files. Try du -sh $file vs du -sh --apparent-size $file , the first bit is the actual on disk size. That's the only one that really matters.
ok, then the bug seems to be fixed in current git. (just a side notice: when I do switch from git version of virt-manager to the installed v0.10.0, then the created vm1 suddenly lacks the conndction of the virtual CD-ROM to the ISO file on my disk - I had to re-connect it)
(In reply to Toralf Förster from comment #12) > ok, then the bug seems to be fixed in current git. > Thanks for confirming, I'll close this. > (just a side notice: when I do switch from git version of virt-manager to > the installed v0.10.0, then the created vm1 suddenly lacks the conndction of > the virtual CD-ROM to the ISO file on my disk - I had to re-connect it) I don't quite follow, but if you think this is a bug in upstream git, please open a separate report.