Bug 855640
Summary: | Unusable very slow inbound network to macvtap VMs | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Davies <richard> |
Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | amit.shah, arnold.x.wang, berrange, brian, cfergeau, crobinso, dwmw2, igeorgex, itamar, javier.wilson, joanayma, knoel, pbonzini, rjones, scottt.tw, stik3mup, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-07-11 19:19:48 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Richard Davies
2012-09-09 14:06:51 UTC
Bug 853669 may be related. I have written a new report since I can give full reproduction instructions using only Fedora 17 for the virtualization host and the VM - no Windows 7 is required. I believe this is a bug in the macvtap kernel component, as discussed but not yet solved in this thread: http://marc.info/?t=134511098600002 Note: For some reason, this bug shows up most clearly on faster networks - i.e. it replicates best on a wired gigabit ethernet network. On slower networks like wifi, the bug is less easily distinguished and also seemingly less severe(!) *** Bug 853669 has been marked as a duplicate of this bug. *** I can confirm. Speed slows down to 5KB/s I am using macvtap and have a gigabit ethernet network. I solved the problem switching from "default" NIC to "virtio" which supports gigabit speeds. I just wanted to comment that my host machine and my switch were both using gigabit speeds. This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. I'm pretty sure this isn't an issue with latest kernels, but someone reopen if they can reproduce on F19. Can confirm this bug on Fedora 19 on latest kernel 3.9.5-301.fc19.x86_64, virt-manager-0.10.0-1, qemu-1.4.2-4. CPU: Intel Core i7. NIC: Realtek RTL8168evl. Tried with virtio and others with same result. The discussion on this thread http://marc.info/?t=134511098600002 suggests that's a CONFIG_INTEL_IDLE but also bug is present on AMD also. I can also confirm this bug on a Fedora 19 setup. kernel - 3.10.6-200.fc19.x86_64 qemu - 1.4.2-5 Having the problem across multiple Dell PowerEdge servers (1950, R610, R710, R810) all with Intel Xenon processors and various Broadcom NIC models. Outbound speeds are normal, but anything inbound extremely slow. I had these same symptoms on a RHEL6 host with a RHEL6 guest. Turning off generic receive offload on the NIC I was using for macvtap solved the problem for me; e.g. ethtool -K eth0 gro off This workaround is described at https://access.redhat.com/site/solutions/349403 |