Red Hat Bugzilla – Bug 593333
virt-manager: Fix automatic keymap resolution
Last modified: 2010-11-10 16:53:49 EST
QEMU and gtk-vnc in RHEL6 cooperate to transparently use the host keymap in the guest. However, virt-manager is incorrectly trying to guess the desired keymap, which overrides the qemu/gtk-vnc behavior.
This is fixed by the upstream commit:
Before and after the patch, do the following:
- Create a guest with virt-manager.
- virsh dumpxml $vmname | grep keymap
Before the patch, there will be a keymap= returned
After the patch, no keymap will be specified.
FYI, if there is no keymap= value in the XML and the guest has messed up keymap, it isn't a virt-manager issue.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Created attachment 414882 [details]
Straight backport from upstream
Fix built in virt-manager-0.8.4-3.el6
Test with virt-manager-0.8.4-6.el6, Create a guest with virt-manager, then virsh dumpxml $vmname | grep keymap, there is only a '<graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>' returned, and get the same testing result with **virt-manager-0.8.4-2.el6**.
Is that the expected result ?
Created attachment 430092 [details]
Proper fix for VNC keymap issue
Good catch, the original patch only pulled one half of the default device model fixes. This patch now contains the important part.
Proposing as a blocker: the additional change to fix this bug is small and low risk. Not fixing this in 5.0 will definitely yeild bug reports from users, since current behavior falls back to en-us keymap setting for most new virtual machines.
Fix built in virt-manager-0.8.4-7.el6
Verified with virt-manager-0.8.4-7.el6.
Create a guest with virt-manage, then virsh dumpxml $vmname | grep keymap, nothing returned.
Verified Passed with virt-manager-0.8.4-8.el6.noarch.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.