Bug 558195 - kvm: NFS : kvm-qemu-img convert failure on RAW/Sparse template with COW/Sparse snapshot
Summary: kvm: NFS : kvm-qemu-img convert failure on RAW/Sparse template with COW/Spars...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-24 10:31 UTC by Oded Ramraz
Modified: 2013-01-09 22:14 UTC (History)
8 users (show)

Fixed In Version: kvm-83-154.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 07:54:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0271 0 normal SHIPPED_LIVE Important: kvm security, bug fix and enhancement update 2010-03-29 13:19:48 UTC

Description Oded Ramraz 2010-01-24 10:31:23 UTC
Description of problem:


I'm using RHEVM with NFS data center.
After creating snapshot from RAW/Sparse template ( the snapshot is sparse qcow2 file ) i try to create a new template from this snapshot, this operation translates to kvm-qemu-cmd ( see Additional Information ).
The operation return immediately without any error although the template creation operation has failed and when i try to run VM with this image i get black screen with "no bootable device" error message.
When i try to perform the same operation on the template file (RAW) it works just fine.

Version-Release number of selected component (if applicable):




How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:

Additional info:

My chain is :
A.Template: RAW/Sparse 
B.Snapshot  COW/Sparse 
Trying to convert snapshot (B) to qcow2:

usr/bin/qemu-img convert -f qcow2 /rhev/data-center/00000000-0000-0000-0000-000000000002/00000000-0000-0000-0000-000000000011/images/4d0c1976-3858-4fa9-8888-85a645407c46/498aba55-1b56-4b5a-b9ec-87ec2a02381b -O qcow2 /tmp/oded

Comment 1 Oded Ramraz 2010-01-24 15:46:44 UTC
This bug occurs also on this chain (NFS):
A.Template: COW/Sparse
B.Snapshot: COW/Sparse 

/usr/bin/qemu-img convert -f qcow2 [path to B] -O qcow2 /tmp/oded

Comment 2 Lawrence Lim 2010-01-25 01:20:00 UTC
Just wondering, is it possible to reproduce this without RHEV-M? So we could add it to autotest as part of regression testing.

Comment 3 Oded Ramraz 2010-01-25 07:51:02 UTC
This operation does not raise any error but if you'll take template which installed with certain OS and create snapshot from this template ,
then perform qemu-img convert operation on this snapshot as seen aforementioned and create snapshot from the new template, If you'll run VM from the new snapshot and wait for IP connectivity, you would fail after some timeout because VM is stuck with "no bootable device" error message.

I will be happy to help you to reproduce this bug without RHEVM intervention.

Comment 4 Miya Chen 2010-01-25 08:21:48 UTC
Test with above steps in kvm-83-148, this bug can be reproduced 

steps:
1. Create external qcow2 snapshot based on raw image:
#qemu-img create -F raw -f qcow2 -b win28k-64.raw win28k-snap1.qcow2
2. Create template from the snapshot:
#qemu-img convert -f qcow2 win28k-snap1.qcow2 -O qcow2 win28k-snap2.qcow2
3. Boot guest with win28k-snap2.qcow2:
#/usr/libexec/qemu-kvm -drive file=win28k-snap2.qcow2,if=ide -no-hpet -rtc-td-hack -usbdevice tablet -startdate now -smp 4 -m 4G -net nic,macaddr=20:20:20:11:23:99,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu qemu64,+sse2 -monitor stdio -vnc :8

Actual result:
got "no bootable device" in screen

Comment 5 Miya Chen 2010-01-25 08:47:50 UTC
1.
# qemu-img info win28k-64.raw
image: win28k-64.raw
file format: raw
virtual size: 25G (26843545600 bytes)
disk size: 8.4G
2.
# qemu-img info win28k-snap1.qcow2 
image: win28k-snap1.qcow2
file format: qcow2
virtual size: 25G (26843545600 bytes)
disk size: 20M
cluster_size: 65536
backing file: win28k-64.raw (actual path: win28k-64.raw)
3.
# qemu-img info win28k-snap2.qcow2 
image: win28k-snap2.qcow2
file format: qcow2
virtual size: 25G (26843545600 bytes)
disk size: 20M
cluster_size: 65536

Comment 6 Kevin Wolf 2010-01-25 09:48:02 UTC
The report says that you found this bug in 5.4, for which I can't reproduce it. However, I can reproduce it on 5.5. Please confirm if this matches what you are seeing.

For reproducing it automatically, I use the following script snippet. Maybe QA wants to use it as well.

QEMU_PATH="."
QEMU_IMG="$QEMU_PATH/qemu-img"
QEMU_IO="$QEMU_PATH/qemu-io test.qcow2"

$QEMU_IMG create -f qcow2 test.qcow2 6G
$QEMU_IO <<EOF
write 2M 4M -P 65
EOF
$QEMU_IMG check test.qcow2
mv test.qcow2 backing.qcow2

$QEMU_IMG create -f qcow2 -b backing.qcow2 test.qcow2
$QEMU_IO <<EOF
write 4M 4M -P 97
EOF
$QEMU_IMG check test.qcow2
mv test.qcow2 overlay.qcow2

$QEMU_IMG convert -f qcow2 overlay.qcow2 -O qcow2 test.qcow2
$QEMU_IO <<EOF
read 2M 2M -P 65
read 4M 4M -P 97
EOF
$QEMU_IMG check test.qcow2

Comment 15 errata-xmlrpc 2010-03-30 07:54:03 UTC
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/RHSA-2010-0271.html


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