Bug 622684

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.

If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.

Hmm, is this virt-convert specific? If you take the original file and just try to run it with /usr/libvirt/qemu-kvm, does it work? If you then convert the original file to qcow2 using qemu-img, and again run it manually with qemu-kvm, does that work?

Basically, is it the virt-convert step that breaks things, or maybe qemu-img, or maybe the binary doesn't work

qemu-kvm command when start domain:
ps aux |grep kvm|grep ESX3.5-RHEL6-64b-20100909.1
qemu     28502  9.9  0.2 1305108 23604 ?       Sl   16:54   4:17 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name ESX3.5-RHEL6-64b-20100909.1 -uuid fba69155-ee15-f867-3e81-4402469bc71b -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/ESX3.5-RHEL6-64b-20100909.1.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/ESX3.5-RHEL6-x64-20100807.0/ESX3.5-RHEL6-x64-20100807.0-flat.qcow2,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=28,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:ad:b8:63,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:3 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

convert to qcow2 with qemu-img:
qemu-img convert -O qcow2 ESX3.5-RHEL6-x64-20100807.0-flat.vmdk ESX3.5-RHEL6-x64-20100807.0-flat.qcow2

the same problem as before. I think it is qemu-img problem

> -drive
> file=/var/lib/libvirt/images/ESX3.5-RHEL6-x64-20100807.0/ESX3.5-RHEL6-x64-20100807.0-flat.qcow2,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none

There is the problem - the disk is set to  format=raw, rather than format=qcow2. Which must in turn mean the XML config is wrong.

(In reply to comment #6)
> > -drive
> > file=/var/lib/libvirt/images/ESX3.5-RHEL6-x64-20100807.0/ESX3.5-RHEL6-x64-20100807.0-flat.qcow2,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none
> 
> There is the problem - the disk is set to  format=raw, rather than
> format=qcow2. Which must in turn mean the XML config is wrong.

ah, yes. The problem is that after I virt-convert vmx to qcow2, there is a file ESX3.5-RHEL6-x64-20100807.0.virt-image.xml created, with 
> <disk file="ESX4-RHEL5U4-x86_64-kvm-smp-flat.qcow2" use="system"
format="raw"/>

After I create the domain with virt-image, it shows <driver type='raw'>, so that is the problem. After change type from 'raw' to 'qcow2', it works well, so no problem on qemu-img, sorry for wrong conclusion before.

There is another problem that after I manually change the ESX3.5-RHEL6-x64-20100807.0.virt-image.xml from <disk format="raw"/> to <disk format="qcow2"/>, with virt-image to create domain, the driver type is also 'raw', but not 'qcow2'.

Thanks for the thorough report, fixed upstream now:

http://hg.fedorahosted.org/hg/python-virtinst/rev/4e218aaddb42

Fix built in python-virtinst-0.500.5-1.el6

Okay, I fixed virt-image to do the right thing, but virt-convert was still handling 'format' in a funky way. Fixed upstream:

http://hg.fedorahosted.org/hg/python-virtinst/rev/08bf078b2229

Fixed in python-virtinst-0.500.5-2.el6

> Fixed in python-virtinst-0.500.5-2.el6

I can confirm this fixes guest creation with virt-image when using qcow2.

Thanks!

Verified on python-virtinst-0.500.5-2.el6
# rpm -qa|grep python-virtinst
python-virtinst-0.500.5-2.el6.noarch

# virt-convert -i vmx -o virt-image -D qcow2 ESX3.5-RHEL6-x64-20100807.0.vmx
Generating output in 'virt-image' format to ESX3.5-RHEL6-64b-20100909.1/
Converting disk 'ESX3.5-RHEL6-x64-20100807.0-flat.vmdk' to type qcow2...
Done.
# ls ESX3.5-RHEL6-64b-20100909.1/
ESX3.5-RHEL6-64b-20100909.1.virt-image.xml
ESX3.5-RHEL6-x64-20100807.0-flat.qcow2
# virt-image -n test ESX3.5-RHEL6-64b-20100909.1.virt-image.xml 
# cat ESX3.5-RHEL6-64b-20100909.1.virt-image.xml 
...........
<storage>
  <disk file="ESX3.5-RHEL6-x64-20100807.0-flat.qcow2" use="system" format="qcow2"/>
 </storage>
...........
# virsh list --all
 Id Name                 State
----------------------------------
 40 test                 running
the guest worked well.
the bug is fixed.

According to comment #18, move to VERIFIED.

verified this bug with:
Linux localhost.localdomain 2.6.32-130.el6.x86_64 #1 SMP Tue Apr 5 19:58:31 EDT
2011 x86_64 x86_64 x86_64 GNU/Linux

python-virtinst-0.500.5-3.el6.noarch
libvirt-0.8.7-17.el6.x86_64

passed.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
virt-convert did not preserve the storage format in the generated xml configuration file causing some image files to fail to boot with the error "no bootable device". The xml configuration now correctly preserves the storage format allowing the image to boot successfully. (BZ#622684)

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-virt-convert did not preserve the storage format in the generated xml configuration file causing some image files to fail to boot with the error "no bootable device". The xml configuration now correctly preserves the storage format allowing the image to boot successfully. (BZ#622684)+virt-convert did not preserve the storage format in the generated xml configuration file causing some image files to fail to boot with the error "no bootable device". The xml configuration now correctly preserves the storage format allowing the image to boot successfully.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0636.html