Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Dear qemu-kvm maintainer,
I am coming from the community: Scientific Linux 6.6, x64 (I would upgrade to 7, except there is no Wine 32 support, which is a deal killer).
Would it be possible to take advantage of Red Hat's stated intention of support for EL6 till 2020 and have a whack at this bug?
I first reported it over on QEMU on https://bugs.launchpad.net/qemu/+bug/1458121
Dear Qemu,
Spice told me to report this over here.
Scientific Linux 6.6
$ uname -r
2.6.32-504.16.2.el6.x86_64
$ cat /etc/redhat-release
Scientific Linux release 6.6 (Carbon)
$ rpm -qa qemu\*
qemu-img-0.12.1.2-2.448.el6_6.3.x86_64
qemu-kvm-0.12.1.2-2.448.el6_6.3.x86_64
I have a bootable USB2 FC21 flash drive. I can boot my machine
directly from it or run it as a virtual machine through KVM.
Problem: it is about 5 times slower through KVM. (Really, I am
not exaggerating)
Their answer was:
That version was a pre-alfa version of kvm support in qemu, is insanely
outdated, is heavily patched by redhat. I don't even think USB2 was
supported by that version. Please try on a current version of qemu and
kernel and reopen if the problem persist there.
Changed in qemu:
status: New → Invalid
So, it is sort of in your court now.
Many thanks,
-T
> Would it be possible to take advantage of Red Hat's stated intention of
> support for EL6 till 2020 and have a whack at this bug?
Not all bugs are equal and not every issue gets fixed in RHEL-6, especially after RHEL-7 release. Security issues have highest priority obviously. Bad performance is at the other end of the scale ...
> I have a bootable USB2 FC21 flash drive. I can boot my machine
> directly from it or run it as a virtual machine through KVM.
>
> Problem: it is about 5 times slower through KVM. (Really, I am
> not exaggerating)
There is a per-request overhead which hardly can be avoided, so in kvm it always will be slower. How much also depends on guest behavior. If the guest is good at grouping requests and requesting larger blocks at once it'll be faster.
> That version was a pre-alfa version of kvm support in qemu, is insanely
> outdated, is heavily patched by redhat. I don't even think USB2 was
> supported by that version.
Which is correct, usb 2.0 support was backported.
> Please try on a current version of qemu and
> kernel and reopen if the problem persist there.
Did you try? Chances are good that RHEL-7 will perform better.
(In reply to Gerd Hoffmann from comment #2)
>
> > Please try on a current version of qemu and
> > kernel and reopen if the problem persist there.
>
> Did you try? Chances are good that RHEL-7 will perform better.
Hi Gerd,
I am still in the process of upgrading to SL 7.1 from SL 6.6. I have 7.1 in a VM and whack at it piece by piece. I have finally got the 32 Wine problem solved. (I posted instructions for everyone to use, let me know if you/anyone would like the link.) and am currently working on porting my firewall. I do believe I have finally got past the systemctl issues. Got 32 bit Acrord working (the wonderfully done PDF Studio does not support Dynamic XFA files).
So, no, I haven't tried yet. Upgrading to 7.1 is no small undertaking. When I am ready, it will be a total wipe and reinstall. It may be two to three months off. But, I will get there eventually.
-T
Comment 5RHEL Program Management
2015-08-21 19:25:26 UTC
Product Management has reviewed and declined this request.
You may appeal this decision by reopening this request.