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:
Only one can be received when sent multiple duplicate key-codes to the guest.
Version-Release number of selected component (if applicable):
kernel-2.6.32-251.el6
libvirt-0.9.10-6.el6
netcf-0.1.9-2.el6
qemu-kvm-0.12.1.2-2.251.el6
How reproducible:
always
Steps to Reproduce:
1.#virsh send-key<domain> 0x10 0x11 0x10
==>the "qwq" will be shown on guest console, it's a expected result.
2.#virsh send-key<domain> 16 17 16
==>the "qwq" will be shown on guest console, it's a expected result.
3.#virsh send-key<domain> 0x10 0x10 0x10
==>the "q" will be shown on guest console, it's a unexpected result.
4.#virsh send-key<domain> 16 16 16
==>the "q" will be shown on guest console, it's a unexpected result.
Actual results:
Guest console can receive multiple duplicate key-codes.
Expected results:
Only one can be received when sent multiple duplicate key-codes to the guest.
The sendkey command in qemu is to emulate keyboard events. Use - to press several keys simultaneously for combination key events(such as ctl-alt-f1). If you want to press multiple duplicated key-codes, the effect is the same as the case that only one key is pressed, so it makes sense to give only one letter in your cases in guest.
BTW, when I tried it by hand in qemu-kvm monitor console, the result is like what I said above. so I don't think this is a bug in both libvirt and qemu.
If I am wrong, this is not a libvirt bug at least.
Guannan, that makes sense. So what would the correct command be to send multiple keystrokes, for example, if a user wanted to send the string "qqq" or "reboot" ?
I think if we still want to use sendkey to do that, we could invoke the command with the same letter multiple times.like the follows for "qqq"
virsh send-key <domain> 0x10
virsh send-key <domain> 0x10
virsh send-key <domain> 0x10
Or use virtio-serial for data messaging between host and guest.