Hide Forgot
Description of problem: After update to 5.6, all the qcow2 based VMs stopped booting. Manually starting them with the disk type set to qcow2 works, but updating the xml manually doesn't help, it gets overwritten to 'raw' by virt-manager and virsh, with no consideration for the actual disk type. Created a new volume of the qcow2 type and attached to domain - still can see it set to 'raw' in the xml for that domain Tested same on F14 - seems to be working correctly Version-Release number of selected component (if applicable): RHEL5.6 libvirt-0.8.2-15.el5_6.1 libvirt-devel-0.8.2-15.el5_6.1 libvirt-devel-0.8.2-15.el5_6.1 libvirt-python-0.8.2-15.el5_6.1 libvirt-0.8.2-15.el5_6.1 How reproducible: Always on 5.6, used to work on 5.5 Steps to Reproduce: 1.create a new qcow2 volume 2.create a new VM, attach the qcow2 vol. 3.start VM and check the xml file - Actual results: will see the VM not booting and xml has 'raw' in the disk settings Expected results: volume settings should not be overwritten to 'raw' in the xml file Additional info: reproduced internally.
Also tried to edit the xml manually, change type back to qcow2. It gets overwritten back to 'raw' anyway
I'm not able to reproduce this problem. I tried the following sequence: 1. virsh start rhel5clone 2. cat > disk.xml <<EOF <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/extra1.img'/> <target dev='vda' bus='virtio'/> </disk> EOF 3. virsh attach-device rhel5clone disk.xml 4. virsh dumpxml rhel5clone <domain type='kvm' id='1'> <name>rhel5clone</name> <uuid>8c286c95-4828-fa98-e84d-81f034025241</uuid> <memory>419200</memory> <currentMemory>418816</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='rhel5.4.0'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'> <timer name='pit' tickpolicy='delay'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/rhel5clone.img'/> <target dev='hda' bus='ide'/> <alias name='ide0-hd0'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/extra1.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2b5a'/> </disk> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <interface type='bridge'> <mac address='00:16:36:2d:45:a9'/> <source bridge='xenbr1'/> <ip address='192.168.122.5'/> <target dev='vnet0'/> <filterref filter='clean-traffic'> <parameter name='IP' value='192.168.122.5'/> </filterref> </interface> <serial type='pty'> <source path='/dev/pts/2'/> <target port='0'/> </serial> <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <target port='0'/> </console> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> </devices> </domain> It still reports qcow2 for the 2nd disk as expected. In addition using 'define' works too 1. virsh dumpxml rhel5clone > a.xml 2. virsh destroy rhel5clone 3. virsh define a.xml 4. virsh dumpxml rhel5clone still reports 'qcow2'. What is the precise sequence of virsh operations used to reproduce the problem ?
editing the xml with virsh edit works attaching the screenshots of my steps virt1 and virt2.png, their result is: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/test123.img'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk>
Created attachment 476551 [details] creating volume
Created attachment 476552 [details] attaching volume to VM
Ok, this is likely a virt-manager problem, because that sequence you show probably relies on QEMU being able to probe the volume format. Please attach the $HOME/.virt-manager/virt-manager.log file.
http:/10.35.24.10/share/virt-manager.log I've cut it down to only todays' events
(In reply to comment #7) > http:/10.35.24.10/share/virt-manager.log > I've cut it down to only todays' events I can't get to that (even after correcting the obvious mistake in the URL). Can you attach it instead?
Created attachment 476568 [details] virt-manager.log
*** Bug 643234 has been marked as a duplicate of this bug. ***
Yeah this slipped of my radar, deferring to 5.8
After evaluating this, providing UI to change this value for existing disk images would be way to invasive for the old old version of virt-manager in RHEL5. Also given that there hasn't been any customer complaints about this, I don't think this is worth backporting for RHEL5, the only real option is a rebase which likely isn't going to happen either. This is all properly fixed in RHEL6. Any users that are having issues will need to use 'virsh edit' to fix things. Closing as WONTFIX for RHEL5