Bug 531958
Summary: | kvm guests' network rx (tap+virtio-net) can break during migration | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Charles Duffy <charles_duffy> |
Component: | kvm | Assignee: | Michael S. Tsirkin <mst> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 5.6 | CC: | cpelland, jfeeney, koj, llim, tburke, virt-maint |
Target Milestone: | rc | Flags: | mst:
needinfo+
mst: needinfo+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-09-12 13:45:19 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 580948 |
Description
Charles Duffy
2009-10-30 00:35:06 UTC
Removing from "Dell Confidential". Will transmit reproducer out-of-band if necessary. Built a debug version of kvm (changed -O2 -g in CFLAGS to -O1 -ggdb) to inspect. Comparing the VirtIONet struct from a single pair of known-good and known-bad savevm images, the following differences jump out at me. From the good image: n->vdev.isr=1 n->vdev.pci_dev.irq_state = {1,0,0,0} n->mergeable_rx_bufs=0 From the bad image: n->vdev.isr=0 n->vdev.pci_dev.irq_state = {0,0,0,0} n->mergeable_rx_bufs=1 I have a packaged reproducer, with the libvirt dependency removed, containing one known-good and one known-bad sample VM. Its run script has support for, among other things, invoking qemu-kvm through gdb. As these VMs were taken from our automated testing system, rather than built as minimal reproducers from the ground up, they're a bit larger than what an ideal minimal testcase might comprise -- the archive containing them weighs in at 741MB; with its content decompressed, 4.3GB of working space is needed. Is this likely to be of use to 'yall? If so, is there somewhere I should upload it? Yes, it will be very helpful to get good and bad images so that we can look at them. You can upload the files to dropbox: http://kbase.redhat.com/faq/docs/DOC-2113 After you do, please provide exact filenames, MD5 or SHA1 message digest of the uploaded files. (In reply to comment #4) > Yes, it will be very helpful to get good and bad images > so that we can look at them. You can upload the files to > dropbox: > http://kbase.redhat.com/faq/docs/DOC-2113 > > After you do, please provide exact filenames, MD5 or SHA1 message digest of the > uploaded files. rhbz531958-reproducer.pax MD5: bc5b1fc8beb1431fcc27d19d1ed7fc50 SHA1: d07029c457d4a3be36d8c85676b09208261d42fc I downloaded the files and the hash matches. I unpacked the pax archive, but I have trouble decompressing both disk and ram images. the error I get is: Unexpected end of input $ sha1sum rhbz531958-reproducer.pax d07029c457d4a3be36d8c85676b09208261d42fc rhbz531958-reproducer.pax $ md5sum rhbz531958-reproducer.pax bc5b1fc8beb1431fcc27d19d1ed7fc50 rhbz531958-reproducer.pax $ pax -rvf rhbz531958-reproducer.pax rhbz531958-reproducer rhbz531958-reproducer/run rhbz531958-reproducer/net.setup rhbz531958-reproducer/data.known_good rhbz531958-reproducer/data.known_good/ramsave.xml rhbz531958-reproducer/data.known_good/env rhbz531958-reproducer/data.known_good/ramsave.raw.xz rhbz531958-reproducer/data.known_good/ramsave.argv rhbz531958-reproducer/data.known_good/da.qcow2.xz rhbz531958-reproducer/data.known_bad rhbz531958-reproducer/data.known_bad/ramsave.xml rhbz531958-reproducer/data.known_bad/env rhbz531958-reproducer/data.known_bad/ramsave.raw.xz rhbz531958-reproducer/data.known_bad/da.qcow2.xz rhbz531958-reproducer/README rhbz531958-reproducer/net.up pax: ustar vol 1, 16 files, 775176192 bytes read, 0 bytes written. $ cd rhbz531958-reproducer/ $ xz -k -d data.known_bad/da.qcow2.xz xz: data.known_bad/da.qcow2.xz: Unexpected end of input Am I doing the right thing? Is this a problem with the uploaded files? Thanks! The issue is on my end -- the .xz files packaged in that pax archive were indeed corrupt. A corrected version is uploading presently. rhbz531958-reproducer.pax Len: 2528860160 (2.4G) MD5: 700723a25aec72a66ba725dd0eeace52 SHA1: f085d7ae237df765ce8a6157dba538c4b5be6d12 I think this is fixed in latest kvm: kvm-83-105.el5_4.22 Specifically, after running this command: env DATA_DIR=data.known_bad ./run -nographic I was able to ssh into guest at address 192.168.0.2 In other words, after updating kvm, it can load the image and networking works. Charles, could you confirm this please? No info yet, so - postpone for 5.6 Since it is too late to address this issue in RHEL 5.5, it has been proposed for RHEL 5.6. Contact your support representative if you need to escalate this issue. |