RFC: Compute resource: set display type and keyboard layout

ovirt
libvirt

#1

Hey,
I had a very interesting talk regarding the support of the following 2 functionalities from within Foreman. This way primarily focused on oVirt, but I see some overlap with other compute resources:

  • Setting display type
    I noticed that we can set the display type for libVirt as well as for VMWare. In oVirt, the default is Spice, although there are benefits to Spice, the HTML5 implementation isn’t all that robust at times.
    My proposal here would be to also give the same choice to oVirt users, by allowing them to set the display technology in the compute resource configuration instead
  • VNC: Setting keyboard layout
    Because, unlike Spice, VNC needs to know which keyboard layout will be used. If there’s a mismatch, it could become frustrating to type a decent text or a complex password. In my case, I’m from Belgium and we actually use an AZERTY layout. By default, oVirt select en-US which breaks our neat flow of creating a VM and instantly using it.
    My proposal here would be to allow the selection of keyboard layout both as part of the compute resource configuration; to act as a default but also as part of the machine configuration to deviate from the default. This would take a way the need to have to change the keyboard layout after VM creation into the oVirt console, for which only a select happy few would have access to.

To be complete: oVirt has the concept of templates which could set this problem straight. However, if one already has templates for certain purposes, and he/she would like to support different keyboard layouts, this would mean every permuation should be created for each keyboard layout. I work for an international company, so this would become a maintenance hell at some point

Now, because all this is opinionated to my situation, in which I work for a international company for which different keyboard layouts for different situations is a thing; I’d actually like figure out if:

  1. First of all, if anyone else ever encountered this as an issue? Maybe I’m the first and I’m overlooking something here.
  2. It would make sense to, just like with libvirt & VMWare resources, also allow oVirt resources to select a display type?
  3. If it would make sense that a user can select a keyboard layout for a specific virtual machine at all?

To give some more input:
What I coded looks like this:

Compute Resource Options

Virtual Machine Options

The trigger of this RFC can be found here:

Kind regards,
Arend


#3

Do I understand correctly that this is the layout of your physical keyboard? Then I’d probably move the keyboard layout to User rather than to host. It’s usually a thing you set only once and never change.

If this is actually layout of the console keyboard, then I recommend to bind this with the host param called “keyboard” which defines it well for PXE-booted hosts:

If we add the very same to the default cloud-init and finish templates, then this will be seamless experience for users - it will work out-of-box without even thinking about this. You can just add some helper bubble next to Display Type label: “Keyboard layout must be set via host param named ‘keyboard’.” This way you don’t need to add a new field to the forms at all!


#4

Hey @lzap

It is, in fact, for the virtual console.

lzap, love the way you’re thinking! I also had the exact same thoughts on the matter but, unfortunately, there seems to be a mismatch between the console keyboard layout and the OS layout. (the problem gets even worse looking at the entire spectrum of keyboard layout identifiers, e.g. windows…). I think, ideally, there would need to be some way of “translating” the virtual keyboard layout identifier to the OS’ keyboard layout identifier to make the experience completely seamless. Still, I think there are possibilities of achieving that and I really love the idea!


#5

Yeah, I wish our Host Parameters screen is better, today you need to know the key and value out of your head, if we had some more interactive way that would be better. Foreman comes with many parameters out of box! Maybe we could at least offer a dropdown UI element for that.