Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1057975 - creating a virtual machine with a qcow2 format for the first hard disc failed
Summary: creating a virtual machine with a qcow2 format for the first hard disc failed
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-manager
Version: unspecified
Hardware: i686
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-26 10:00 UTC by Toralf Förster
Modified: 2014-01-27 18:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-27 18:42:49 UTC


Attachments (Terms of Use)
screen shot of qcow2 (deleted)
2014-01-26 19:59 UTC, Toralf Förster
no flags Details
screen shot of the error msg (deleted)
2014-01-26 20:00 UTC, Toralf Förster
no flags Details
/virt-manager --debug 1>~/tmp/virt-manager.log 2>&1 (deleted)
2014-01-27 17:16 UTC, Toralf Förster
no flags Details

Description Toralf Förster 2014-01-26 10:00:28 UTC
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.

Comment 1 Toralf Förster 2014-01-26 10:03:04 UTC
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.

Comment 2 Cole Robinson 2014-01-26 18:07:19 UTC
(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

Comment 3 Toralf Förster 2014-01-26 18:29:06 UTC
(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

Comment 4 Toralf Förster 2014-01-26 18:31:37 UTC
FWIW Python 2.7.5 is my active interpreter here at a x86 Gentoo.

Comment 5 Cole Robinson 2014-01-26 18:36:25 UTC
(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!

Comment 6 Toralf Förster 2014-01-26 19:15:01 UTC
(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
:-)

Comment 7 Toralf Förster 2014-01-26 19:59:54 UTC
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).

Comment 8 Toralf Förster 2014-01-26 20:00:36 UTC
Created attachment 855760 [details]
screen shot of the error msg

Comment 9 Cole Robinson 2014-01-26 20:54:33 UTC
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

Comment 10 Toralf Förster 2014-01-27 17:16:35 UTC
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)

Comment 11 Cole Robinson 2014-01-27 17:56:29 UTC
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.

Comment 12 Toralf Förster 2014-01-27 18:21:53 UTC
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)

Comment 13 Cole Robinson 2014-01-27 18:42:49 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.