Description of problem: By default, the instances are launched with '-k en-us' option. This enables an old code path which has drawbacks for other keyboard mappings. For example French, Belgium and Spanish (and much more) won't be able to use a combination of Alt-gr + Key on the web console. We need to remove the default for the keymap, which is deprecated in modern qemu-kvm as I was told. This way we can get the proper behavior (with some NoVNC patchs, that are upstream, sross made a patch set for RHOSP8). An Upstream bug has been opened on this subject. Regards, Pierre-André
Created attachment 1277313 [details] Remove any default keymap option for kvm (deprecated).
Created attachment 1277316 [details] Backport from Solly Ross for proper keymap support on NoVnc (novnc-0.6.1-1.el7ost.noarch.rpm)
Per comments on the upstream bug, it seems this option is not deprecated. In addition, the man page for qemu-kvm specifically states: -k language Use keyboard layout language (for example "fr" for French). This option is only needed where it is not easy to get raw PC keycodes (e.g. on Macs, with some X11 servers or with a VNC or curses display). You don't normally need to use it on PC/Linux or PC/Windows hosts. Given that we are using VNC, this seems like the correct thing to do. Could we not simply set the correct language in 'nova.conf'?
Hi Stephen, No, even setting the correct keymap doesn't fix the issue. We really need to unset this option. Regards, Pierre-André
(In reply to Pierre-Andre MOREY from comment #9) > Hi Stephen, > > No, even setting the correct keymap doesn't fix the issue. We really need to > unset this option. Yes, Dan Barrange's comments on the upstream bug helped clarify the issue. I've created a patch upstream that deprecates these options and unsets their defaults, similar to what Solly Ross had done previously. I'm not sure if this is likely to land in this cycle, given the short number of days remaining, but I'll work on it. If not, it should land early next cycle and parts of it can probably be backported.
The patch for this is up, but it will have to wait until features can be merged again before getting in. How far do you envision backporting this, Pierre-Andre?
Hi Stephen, Customer is planning a OSP8 to OSP10 upgrade in September, so for me having it in a OSP10 seems sufficient. This also depends on an upstream fix for NoVnc, so both should be backported on the target release. I will check if the novnc shipped with OSP10 already includes the proper NoVnc patch. Regards, Pierre-André
I've split the upstream patch into two parts - one that allows users to unset the configuration option (and warns them about side effects if set), and another that'll deprecate the option and unset the default. The former is backportable while I doubt the latter is. Let's see how we progress.
Hi there, If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to -. Thanks, Alex
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2714