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.
Description of problem:
Sorry, but this bug report will be ranting all over. But the version from RHEL6 is entirely useless for me and I really see no good reason why everything has to be different from upstream.
Issue 1:
The binary is located in /usr/libexec. Why? What is the rationale to make it so difficult to find the binary and not to have it in an standard path? Just to keep users off from doing their work?
Issue 2:
qemu: hardware error: Unknown device 'lsi53c895a' for bus 'PCI'
CPU #0:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006d3
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
[...]
/home/schubert/bin/kvm-centos5: line 22: 12892 Aborted ${kvm} -m 512 -net nic,macaddr=00:0E:0C:B8:C7:34,model=${NICMODEL} -net tap,script=/etc/kvm/kvm-ifup,downscript=/etc/kvm/kvm-ifdown,ifname=$iface -boot dc -drive file=${FILE},if=${DISKIF},boot=on,cache=writeback -enable-kvm "$@"
For this VM I defined:
DISKIF = scsi
Changing DISKIF to ide or virtio makes it work again. So scsi devices do not work at all any more? No idea what is going on the Red Hat maintainer site, but there is a reason why I have chosen scsi over virtio or ide for this VM.
Issue 3:
qemu-kvm: -curses: invalid option
3.1) The man page says "-curses" is a valid config option
3.2)
* Fri Jan 15 2010 Eduardo Habkost <ehabkost> - qemu-kvm-0.12.1.2-2.5.el6
- Remove unneeded/unsupported features: [bz#555336]
3.2.1)
I cannot access this bugzilla, so I do not see the rationale
3.2.2) I entirely disagree, this option is absolutely required by me - I start my VM test cluster from screen and want to be able to walk through the screen tabs and see the output of the VMs. So saying this option is unneeded is pure nonsense.
3.3.3) Unsupported - maybe from your side, so your decision. But why on earth are you then entirely disabling those options?
My qemu-kvm scripts work ever since about 2007 and are mostly unmodified ever since (with the exception of new options such as virtio). But now with qemu-kvm from RHEL6 it fails all over. As the RHEL6 qemu-kvm version seems to be so much different from upstream, maybe the package simply should be renamed? It good candidate probably would be 'non-working-qemu-kvm'.
Sorry for ranting,
Bernd
Would you mind opening individual bugs for each issue? This would help us better triage and evaluate your reports. Some of your concerns are valid, but need to be handled individually.
Due to the way this bug is reported, I would say it's a candidate for being CLOSED as NOTABUG/CANTFIX.
Description of problem: Sorry, but this bug report will be ranting all over. But the version from RHEL6 is entirely useless for me and I really see no good reason why everything has to be different from upstream. Issue 1: The binary is located in /usr/libexec. Why? What is the rationale to make it so difficult to find the binary and not to have it in an standard path? Just to keep users off from doing their work? Issue 2: qemu: hardware error: Unknown device 'lsi53c895a' for bus 'PCI' CPU #0: EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006d3 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 [...] /home/schubert/bin/kvm-centos5: line 22: 12892 Aborted ${kvm} -m 512 -net nic,macaddr=00:0E:0C:B8:C7:34,model=${NICMODEL} -net tap,script=/etc/kvm/kvm-ifup,downscript=/etc/kvm/kvm-ifdown,ifname=$iface -boot dc -drive file=${FILE},if=${DISKIF},boot=on,cache=writeback -enable-kvm "$@" For this VM I defined: DISKIF = scsi Changing DISKIF to ide or virtio makes it work again. So scsi devices do not work at all any more? No idea what is going on the Red Hat maintainer site, but there is a reason why I have chosen scsi over virtio or ide for this VM. Issue 3: qemu-kvm: -curses: invalid option 3.1) The man page says "-curses" is a valid config option 3.2) * Fri Jan 15 2010 Eduardo Habkost <ehabkost> - qemu-kvm-0.12.1.2-2.5.el6 - Remove unneeded/unsupported features: [bz#555336] 3.2.1) I cannot access this bugzilla, so I do not see the rationale 3.2.2) I entirely disagree, this option is absolutely required by me - I start my VM test cluster from screen and want to be able to walk through the screen tabs and see the output of the VMs. So saying this option is unneeded is pure nonsense. 3.3.3) Unsupported - maybe from your side, so your decision. But why on earth are you then entirely disabling those options? My qemu-kvm scripts work ever since about 2007 and are mostly unmodified ever since (with the exception of new options such as virtio). But now with qemu-kvm from RHEL6 it fails all over. As the RHEL6 qemu-kvm version seems to be so much different from upstream, maybe the package simply should be renamed? It good candidate probably would be 'non-working-qemu-kvm'. Sorry for ranting, Bernd