Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Descriptionhyao@redhat.com
2014-01-06 06:50:58 UTC
Clone the bug due to it reproduced on rhel6.5
# rpm -qa libvirt virt-manager
virt-manager-0.9.0-19.el6.x86_64
libvirt-0.10.2-29.el6.x86_64
1. Import a qcow2 image to create a guest.
# qemu-img info kvm-rhel6.5-x86_64-qcow2.img
image: kvm-rhel6.5-x86_64-qcow2.img
file format: qcow2
virtual size: 3.9G (4194304000 bytes)
disk size: 2.8G
cluster_size: 65536
2. check the disk info in the xml
# virsh dumpxml tmp | grep disk -A 10
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/tmp/kvm-rhel6.5-x86_64-qcow2.img'/>
<target dev='hda' bus='ide'/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
+++ This bug was initially created as a clone of Bug #1044396 +++
Description of problem:
virt-manager doesn't automatically recognize qcow2 when importing image
Version-Release number of selected component (if applicable):
virt-manager-0.10.0-7.el7.noarch
How reproducible:
always
Steps to Reproduce:
1. Create new VM
2. Select: Import existing disk image
3. Provide path to image.
4. Complete setup and boot VM.
Actual results:
VM won't boot from image.
Storage format is in advanced options set to: raw
Expected results:
VM should boot from image.
Storage format in advanced options should be set to: qcow2
Additional info:
tested image: http://alt.fedoraproject.org/pub/fedora/linux/releases/19/Images/x86_64/Fedora-x86_64-19-20130627-sda.qcow2
--- Additional comment from tingting zheng on 2013-12-19 04:11:25 EST ---
I can not reproduce this issue
version:
virt-manager-0.10.0-8.el7.noarch
Steps:
1.Create qcow2 img.
# qemu-img create qcow2.img 1G -f qcow2
Formatting 'qcow2.img', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off
2.Use virt-manager to create a new vm,importing the image create by step1.
3.Storage format in advanced options is set as:qcow2.
4.Check the xml of the guest,the format of disk also show as qcow2.
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/var/lib/libvirt/images/qcow2.img'/>
<target dev='hda' bus='ide'/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
--- Additional comment from Giuseppe Scrivano on 2013-12-19 04:27:17 EST ---
the directory /var/lib/libvirt/images is a libvirt storage pool. The problem happens when you import an existing image that is not under a storage pool.
--- Additional comment from tingting zheng on 2013-12-19 04:38:53 EST ---
(In reply to Giuseppe Scrivano from comment #2)
> the directory /var/lib/libvirt/images is a libvirt storage pool. The
> problem happens when you import an existing image that is not under a
> storage pool.
Yes,you are right,the image with qcow2 format in other directory instead of libvirt storage pool will show as raw from virt-manager GUI.
--- Additional comment from hyao on 2014-01-06 00:58:56 EST ---
I can reproduce this bug on
# rpm -qa libvirt virt-manager
libvirt-1.1.1-17.el7.x86_64
virt-manager-0.10.0-9.el7.noarch
Steps:
1. Import a qcow2 image to create a guest.
# qemu-img info /tmp/kvm-rhel6.5-x86_64-qcow2.img.1
image: /tmp/kvm-rhel6.5-x86_64-qcow2.img.1
file format: qcow2
virtual size: 3.9G (4194304000 bytes)
disk size: 2.7G
cluster_size: 65536
Format specific information:
compat: 0.10
2. Check the xml of the guest:
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/tmp/kvm-rhel6.5-x86_64-qcow2.img.1'/>
<target dev='hda' bus='ide'/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
Actual Result:
The disk format qcow2 is recognized as raw.
Comment 2Giuseppe Scrivano
2014-01-15 10:09:25 UTC
closing it. The support for detecting not-managed images is not present in virt-manager and unlikely it will hit rhel-6.6
Clone the bug due to it reproduced on rhel6.5 # rpm -qa libvirt virt-manager virt-manager-0.9.0-19.el6.x86_64 libvirt-0.10.2-29.el6.x86_64 1. Import a qcow2 image to create a guest. # qemu-img info kvm-rhel6.5-x86_64-qcow2.img image: kvm-rhel6.5-x86_64-qcow2.img file format: qcow2 virtual size: 3.9G (4194304000 bytes) disk size: 2.8G cluster_size: 65536 2. check the disk info in the xml # virsh dumpxml tmp | grep disk -A 10 <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source file='/tmp/kvm-rhel6.5-x86_64-qcow2.img'/> <target dev='hda' bus='ide'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> +++ This bug was initially created as a clone of Bug #1044396 +++ Description of problem: virt-manager doesn't automatically recognize qcow2 when importing image Version-Release number of selected component (if applicable): virt-manager-0.10.0-7.el7.noarch How reproducible: always Steps to Reproduce: 1. Create new VM 2. Select: Import existing disk image 3. Provide path to image. 4. Complete setup and boot VM. Actual results: VM won't boot from image. Storage format is in advanced options set to: raw Expected results: VM should boot from image. Storage format in advanced options should be set to: qcow2 Additional info: tested image: http://alt.fedoraproject.org/pub/fedora/linux/releases/19/Images/x86_64/Fedora-x86_64-19-20130627-sda.qcow2 --- Additional comment from tingting zheng on 2013-12-19 04:11:25 EST --- I can not reproduce this issue version: virt-manager-0.10.0-8.el7.noarch Steps: 1.Create qcow2 img. # qemu-img create qcow2.img 1G -f qcow2 Formatting 'qcow2.img', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off 2.Use virt-manager to create a new vm,importing the image create by step1. 3.Storage format in advanced options is set as:qcow2. 4.Check the xml of the guest,the format of disk also show as qcow2. <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/qcow2.img'/> <target dev='hda' bus='ide'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> --- Additional comment from Giuseppe Scrivano on 2013-12-19 04:27:17 EST --- the directory /var/lib/libvirt/images is a libvirt storage pool. The problem happens when you import an existing image that is not under a storage pool. --- Additional comment from tingting zheng on 2013-12-19 04:38:53 EST --- (In reply to Giuseppe Scrivano from comment #2) > the directory /var/lib/libvirt/images is a libvirt storage pool. The > problem happens when you import an existing image that is not under a > storage pool. Yes,you are right,the image with qcow2 format in other directory instead of libvirt storage pool will show as raw from virt-manager GUI. --- Additional comment from hyao on 2014-01-06 00:58:56 EST --- I can reproduce this bug on # rpm -qa libvirt virt-manager libvirt-1.1.1-17.el7.x86_64 virt-manager-0.10.0-9.el7.noarch Steps: 1. Import a qcow2 image to create a guest. # qemu-img info /tmp/kvm-rhel6.5-x86_64-qcow2.img.1 image: /tmp/kvm-rhel6.5-x86_64-qcow2.img.1 file format: qcow2 virtual size: 3.9G (4194304000 bytes) disk size: 2.7G cluster_size: 65536 Format specific information: compat: 0.10 2. Check the xml of the guest: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source file='/tmp/kvm-rhel6.5-x86_64-qcow2.img.1'/> <target dev='hda' bus='ide'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> Actual Result: The disk format qcow2 is recognized as raw.