Bug 970823 - qemu will be core dump when Storage vm migration on f19
Summary: qemu will be core dump when Storage vm migration on f19
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
(Show other bugs)
Version: 19
Hardware: x86_64 Linux
unspecified
high
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-05 02:08 UTC by zhonglinzhang
Modified: 2013-10-31 21:15 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-31 21:15:46 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description zhonglinzhang 2013-06-05 02:08:28 UTC
Description of problem:
after completing the configuration of src and des, sometimes qemu will be core dump on des 

Version-Release number of selected component (if applicable):
# uname -r
3.9.2-301.fc19.x86_64
qemu-kvm-1.4.1-3.fc19.x86_64

How reproducible:
50%

Steps to Reproduce:
1.des host: 
qemu-img create -f qcow2 test.qcow2 35G
qemu-kvm -cpu SandyBridge -M pc-i440fx-1.4 -enable-kvm -m 4G -smp 4,sockets=2,cores=2,threads=1 -no-kvm-pit-reinjection -name scalability-test -uuid 389d06a7-e631-4fae-baf4-87bdb9b5594e -rtc base=localtime,clock=host,driftfix=slew -drive file=/home/test.qcow2,if=none,id=drive-system-disk,media=disk,format=qcow2,aio=native,werror=stop,rerror=stop -device virtio-blk-pci,bus=pci.0,drive=drive-system-disk,id=system-disk,addr=0x6 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:22:15:27:54:3d,bus=pci.0,addr=0x9    -k en-us -boot menu=on -vnc :0  -vga cirrus -monitor stdio -qmp tcp:0:5555,server,nowait -incoming tcp:0:5888 
{ "execute": "qmp_capabilities" }
{ "execute": "nbd-server-start", "arguments": { "addr": { "type": "inet", "data": { "host": "10.66.6.154", "port": "8888" } } } }
(qemu) nbd_server_add -w drive-system-disk

2.src host: 
qemu-img info fedora19.qcow2 
image: fedora19.qcow2
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 16G
cluster_size: 65536

qemu-kvm -cpu SandyBridge -M pc-i440fx-1.4 -enable-kvm -m 4G -smp 4,sockets=2,cores=2,threads=1 -no-kvm-pit-reinjection -name scalability-test -uuid 389d06a7-e631-4fae-baf4-87bdb9b5594e -rtc base=localtime,clock=host,driftfix=slew -drive file=/home/fedora19.qcow2,if=none,id=drive-system-disk,media=disk,format=qcow2,aio=native,werror=stop,rerror=stop -device virtio-blk-pci,bus=pci.0,drive=drive-system-disk,id=system-disk,addr=0x6 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:22:15:27:54:3d,bus=pci.0,addr=0x9    -k en-us -boot menu=on -vnc :0  -vga cirrus -monitor stdio -qmp tcp:0:5555,server,nowait 
{ "execute": "qmp_capabilities" }
{ "execute": "drive-mirror", "arguments": { "device": "drive-system-disk", "target": "nbd://10.66.6.154:8888/drive-system-disk", "sync": "full", "format": "raw", "mode": "existing" } }

3.migrate -d tcp:$des-host-ip:$port

Actual results:
des:
(qemu) qemu-system-x86_64: block/qcow2-cache.c:67: qcow2_cache_destroy: Assertion `c->entries[i].ref == 0' failed.


Expected results:
qemu can work normally

Additional info:

Comment 1 Cole Robinson 2013-10-31 21:15:46 UTC
Given that the old style storage migration is mostly un maintained, this is unlikely to get fixed. I'd be interested to know if you can trigger a similar assertion with libvirt nbd based storage migration, or the same commands on F20 (since then we can forward the report upstream)


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