Created attachment 425736 [details] showkey -a output in virtual machine Description of problem: In Fedora 13 desktop my keyboard works correctly, but inside any OS run as virtual machine in same box (DOS 7.1, Gentoo, Ubuntu, FreeBSD) pressing keys "<" and ">" produce z and X. Version-Release number of selected component (if applicable): libvirt-0.7.7-4.fc13 (x84_64) libvirt-client-0.7.7-4.fc13 virt-manager-0.8.4 (x84_64) How reproducible: always Steps to Reproduce: 1. Use any os in virtual machine Actual results: press key < (left side of z): z press key > (left side of z with shift): X Expected results: press key < (left side of z): < press key > (left side of z with shift): > Additional info: I tested with both finnish and US keyboard layouts in F13 and virtual machines: always same behavior. Pressing the same key with alt-gr produces "|" as it should. See attached .png files for showkey -a output.
Created attachment 425738 [details] showkey -a output in Fedora 13
Please provide the following extra info - virsh dumpxml $GUESTNAME - The corresponding /var/log/libvirt/qemu/$GUESTNAME.log file from starting the guest
Created attachment 431556 [details] virsh dumpxml $GUESTNAME output Added virsh dumpxml output as attachment.
Created attachment 431559 [details] /var/log/libvirt/qemu/$GUESTNAME.log file
The graphics tag for the guest has an explicit keymap set: <graphics type='vnc' port='5900' autoport='yes' keymap='fi'/> This breaks the automatic scancode mapping that is necessary to get a properly functional keyboard. Shutdown the guest, then use 'virsh edit $GUESTNAME' and remove the keymap='fi' attribute. Then it should be possible to get correct keymap behaviour simply by setting the keymap inside the guest OS. NB this requires use of virt-manager or virt-viewer or vinagre. Traditional vnc clients like TightVNC will never work properly with non-US layouts.
After manually removing the keymap='fi' attribute keyboard works ok in guest OS. I created the guests using Virtual Machine Manager 0.8.4, which seems to generate this attribute while host keyboard layout is not "us".
Sounds like you are hitting 586201 *** This bug has been marked as a duplicate of bug 586201 ***