Remove nova default keymap option for qemu-kvm (deprecated)

[Kick In]

Hi,

Nowdays, qemu-kvm default keymap option -k en-us, or any keymap option is deprecated.

In OpenStack it renders the web console access to vm unsuable even with the proper keymap in nova.conf. For exapmle the use of 'Alt-Gr + key' combination in French, Belgium, spanish, or alike keyboard is not working, this can be problematic for hard passwords.

Using the linked patch and removing/commenting the keymap options in nova.conf, makes everything working again (depending on the NoVnc version which might be patched also on previous ones).

So maybe by default the nova.conf should now comment/remove this option and we need to remove the default option in the nova code.

Regards,
Pierre-André

[jichenjc (jichenjc)]

is there any guideline or links you mentioned above for the deprecation?
And the patch you showed seems only remove the default value, so we need totally deprecate the whole option and don't use it in the future?

[Dinesh Bhor (dinesh-bhor)]

Hi all,

I have confirmed with the qemu community whether -k keymap option is deprecated or not. As per pjp developer, it's not deprecated.

Please find below discussions on the #qemu irc channel.

Got the reference of #qemu channel from http://www.qemu.org/contribute/
IRC: irc.oftc.net, channel #qemu

IRC Logs:

<pre>
<Dinesh_Bhor> Hi all, I have a doubt. Hope someone will answer. Is qemu-kvm default keymap option -k en-us, or any keymap option is deprecated ? If yes where can I find the documentation related to it.
<Dinesh_Bhor> or is there any future plan to deprecate it?
<Dinesh_Bhor> pm215: Hi, can you help me with this? ^^
<pjp> Dinesh_Bhor: I doubt it's deprecated, why do you think it is?
<Dinesh_Bhor> pjp: someone has reported a bug in openstack-nova that this is deprecated: https://bugs.launchpad.net/nova/+bug/1682020
<Dinesh_Bhor> pjp: so I just want to confirm it
<pjp> Dinesh_Bhor: Built qemu from latest git, qemu-system-x86_64 does show -k option,
<Dinesh_Bhor> pjp: it's not showing any deprecation message when you run this command. right?
<pjp> Dinesh_Bhor: Nope
<Dinesh_Bhor> pjp: ok, thank you for your help
<Dinesh_Bhor> pjp: one more question. Where can I find this channel's logs?
<pjp> Dinesh_Bhor: Not sure
<Dinesh_Bhor> pjp: ok, np, thanks
</pre>

Secondly, I have checked ChangeLogs for the last 3 releases and I couldn't see the option -k keymap is deprecated.

http://wiki.qemu.org/index.php?title=Special:AllPages&from=ChangeLog/&to=ChangeLog/zzzzz&namespace=0

<pre>
http://wiki.qemu.org/ChangeLog/2.9
http://wiki.qemu.org/ChangeLog/2.8
http://wiki.qemu.org/ChangeLog/2.7
</pre>

[Yukinori Sagara (sagara)]

In the Dinesh #3 comment above, 'pjp' is 'Prasad J Pandit'.
He has committed many patches to the Qemu project so we assume he has basic knowledge to tell if any parameter is deprecated or not.

http://git.qemu.org/?p=qemu.git;a=search;h=HEAD;s=Prasad+J+Pandit;st=author

[Daniel Berrange (berrange)]

It is more subtle than suggested by that quote IRC conversation.

The "-k" option isn't marked as deprecated in the QEMU docs because it applies to several different areas of the QEMU code, and it can sometimes be valid to use it (primarily for interacting with QEMU via stdin on the text console. If you are using the VNC server though, it is *strongly* recommended to *NEVER* add the "-k" option, because it will force QEMU to do keymap conversions which are known to be lossy. The result is that users (particularly those with non-US layout keyboards) will be unable to enter certain key combinations. Leave out "-k", and allow VNC clients to pass through raw scan codes directly to the guest without any lossy munging by QEMU.

NB, I am a long term maintainer of the QEMU VNC code & the GTK-VNC client.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/483994

[Tushar Patil (tpatil)]

Hi Daniel,

I have checked impact of w/ and w/o -k option with different combinations of default locale configured in client os and guest os.

In case of RHEL image with default locale 'ja_JP' and client default locale set as 'ja_JP', I have noticed that with -k option, only one character was giving problem with Japanese keyboard whereas without -k option I couldn't enter 4 characters and also many other characters were displayed incorrectly.

Presently, -k option passed to qemu can be configured using 'vnc.keymap' parameter on nova compute node, but it's remain the same for all vms running on that particular compute host. If we allow to pass keymap parameter to boot api [1](specs are up for review), then a user can specify which keymap to be used during booting instance based on the keymap that he/she will configure in the client os (machine from where user will access the vm using vnc console). This way, I think user should be able to get better results.

Please let me know what do you think abouut it.

Thank you.

[1] : https://review.openstack.org/#/c/448830

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/496605

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/496605
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d983234288728427235ef2c1f355ec135119b865
Submitter: Jenkins
Branch: master

commit d983234288728427235ef2c1f355ec135119b865
Author: Stephen Finucane <email address hidden>
Date: Wed Aug 23 11:15:17 2017 +0100

    conf: Allow users to unset 'keymap' options

    Defining the 'keymap' option in libvirt results in the '-k' option being
    passed through to QEMU [1][2]. This QEMU option has some uses, primarily
    for users interacting with QEMU via stdin on the text console. However,
    for users interacting with QEMU via VNC or Spice, like nova users do, it
    is strongly recommended to never add the "-k" option. Doing so will
    force QEMU to do keymap conversions which are known to be lossy. This
    disproportionately affects users with non-US keyboard layouts, who would
    be better served by relying on the guest OS to manage this.

    In the long term, we would like to deprecate these options. However, we
    must do this in three parts. This part allows users to unset the options
    and warns users who have them set about the side effects. This change is
    intended to be backported. A future change will fully deprecate the
    options. Finally, after the deprecation cycle has passed, we can remove
    these options in their entirety.

    [1] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L6985-L6986
    [2] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L7215-L7216

    Change-Id: I6b1d719db0537b0f53768dbb00a5b4d01c85ba3a
    Related-Bug: #1682020

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/pike
Review: https://review.openstack.org/498509

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/498509
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ccfb46420d6ee186d6ec777ce6167bd138f2a285
Submitter: Jenkins
Branch: stable/pike

commit ccfb46420d6ee186d6ec777ce6167bd138f2a285
Author: Stephen Finucane <email address hidden>
Date: Wed Aug 23 11:15:17 2017 +0100

    conf: Allow users to unset 'keymap' options

    Defining the 'keymap' option in libvirt results in the '-k' option being
    passed through to QEMU [1][2]. This QEMU option has some uses, primarily
    for users interacting with QEMU via stdin on the text console. However,
    for users interacting with QEMU via VNC or Spice, like nova users do, it
    is strongly recommended to never add the "-k" option. Doing so will
    force QEMU to do keymap conversions which are known to be lossy. This
    disproportionately affects users with non-US keyboard layouts, who would
    be better served by relying on the guest OS to manage this.

    In the long term, we would like to deprecate these options. However, we
    must do this in three parts. This part allows users to unset the options
    and warns users who have them set about the side effects. This change is
    intended to be backported. A future change will fully deprecate the
    options. Finally, after the deprecation cycle has passed, we can remove
    these options in their entirety.

    [1] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L6985-L6986
    [2] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L7215-L7216

    Change-Id: I6b1d719db0537b0f53768dbb00a5b4d01c85ba3a
    Related-Bug: #1682020
    (cherry picked from commit d983234288728427235ef2c1f355ec135119b865)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/547985

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/547985
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ed7af4c8f4d72ed0a1c15daf1c700b07fbeed635
Submitter: Zuul
Branch: master

commit ed7af4c8f4d72ed0a1c15daf1c700b07fbeed635
Author: Matt Riedemann <email address hidden>
Date: Mon Feb 26 05:53:57 2018 -0500

    Update noVNC deployment docs to mention non-US keymap fix in 1.0.0

    noVNC 1.0.0 has the fix for non-US key mappings so this adds a simple
    note when installing the novnc package that at least 1.0.0 should be
    used for non-US key map support.

    Change-Id: Ia1a84c986025f8a46c1062440faa0deb1d2d73a5
    Related-Bug: #1682020

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/queens
Review: https://review.openstack.org/548057

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/548057
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=733b61527da7e1961548966360a9241b2a304014
Submitter: Zuul
Branch: stable/queens

commit 733b61527da7e1961548966360a9241b2a304014
Author: Matt Riedemann <email address hidden>
Date: Mon Feb 26 05:53:57 2018 -0500

    Update noVNC deployment docs to mention non-US keymap fix in 1.0.0

    noVNC 1.0.0 has the fix for non-US key mappings so this adds a simple
    note when installing the novnc package that at least 1.0.0 should be
    used for non-US key map support.

    Change-Id: Ia1a84c986025f8a46c1062440faa0deb1d2d73a5
    Related-Bug: #1682020
    (cherry picked from commit ed7af4c8f4d72ed0a1c15daf1c700b07fbeed635)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/550173

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/483994
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=cab8139498c7ea6b05cfdc8b4997276051b943fc
Submitter: Zuul
Branch: master

commit cab8139498c7ea6b05cfdc8b4997276051b943fc
Author: Stephen Finucane <email address hidden>
Date: Fri Jul 14 17:00:27 2017 +0100

    conf: Deprecate 'keymap' options

    Defining the 'keymap' option in libvirt results in the '-k' option being
    passed through to QEMU [1][2]. This QEMU option has some uses, primarily
    for users interacting with QEMU via stdin on the text console. However,
    for users interacting with QEMU via VNC or Spice, like nova users do, it
    is strongly recommended to never add the "-k" option. Doing so will
    force QEMU to do keymap conversions which are known to be lossy. This
    disproportionately affects users with non-US keyboard layouts, who would
    be better served by relying on the guest OS to manage this. Users should
    instead rely on their clients and guests to correctly configure this.

    This is the second part of the three part deprecation cycle for these
    options. At this point, they are retained but deprecated them and their
    defaults modified to be unset. This allows us to warn users with libvirt
    hypervisors that have configured the options about the pitfalls of the
    option and give them time to prepare migration strategies, if necessary.
    A replacement option is added to the VMWare group to allow us to retain
    this functionality for that hypervisor. Combined with the above, this
    will allow us to remove the options in a future release.

    [1] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L6985-L6986
    [2] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L7215-L7216

    Change-Id: I9a50a111ff4911f4364a1b24d646095c72af3d2c
    Closes-Bug: #1682020

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 18.0.0.0b1 development milestone.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Stephen Finucane (<email address hidden>) on branch: master
Review: https://review.openstack.org/550173
Reason: Realistically, this shouldn't merge until Ubuntu 20.04 is out and Fedora 28 symlinks the path [1] making this unnecessary. Let's abandon this for now.

[1] https://src.fedoraproject.org/rpms/novnc/blob/master/f/novnc.spec#_36

[Olaf Seibert (oseibert-sys11)]

Reading the above, I wanted to take advantage of removing the -t option, and using non-US keyboards. However it turns out that in our Ussuri installation on Bionic, we still get novnc 1:0.4+dfsg+1+20131010+gitf68af8af3d-7.

Would it not be a good idea to have version >= 1.0.0 in the Ubuntu Cloud Archive?

[Olaf Seibert (oseibert-sys11)]

s/-t/-k/