Hi,
I’m just wondering if anyone had succeeded in using a non-us keyboard layout inside a guest running on a kvm opennebula-4.14.x host and accessed via the NoVNC WebUI please ?
I’m running opennebula 4.14.x on a single kvm host and whenever accessing a linux VM (or even a Windows one) via the opennebula-novnc WebUI, i can’t send some char, like the ubiquitous “|” (aka pipe), to the guest :-/
Both the workstation i’m connecting from and the guest are linux OS with locale set to LANG=fr_FR.UTF-8 and i’m using Chrome “Version 53.0.2785.116 (64-bit)”
If i set the “keymap=fr” settings on the vm template, the keyboard layout seems to be set to the traditional fr layout (aka “azerty”) but a lot of the “special char”, like “|”, which should be accessible via “AltGr+6” doesn’t work
And if i don’t set the “keymap=fr” option, the keyboard layout is reverted to the US variant (aka qwerty) inside the guest
As it seems that the NoVNC project had made a lot of progress on this issue and already implemented several workaround as explained on these (lenghty) bug reports: https://github.com/kanaka/noVNC/issues/21 | https://github.com/kanaka/noVNC/issues/666 and i wish there were some instructions on how to update the noVNC version shipped with opennebula in order to test those fixes
I really hope that this issue will be dealt with because if it’s confirmed, the noVNC console, which is a must-have feature of the opennebula plateform, is pretty much useless even when trying to use it for some basic stuff inside the guest
and setting or unsetting the “keymap=fr” settings from the template
would be enough
But using that patched noVNC release or the one shipped with opennebula 4.12.x made no difference
So i thought that as i’m a noob on javascript stuff, i must’ve been doing something wrong
i’m glad you got lucky with “de” layout
I wish i could say the same with the french layout cause right now, the noVNC console is pretty much unusable when you need to type non-alphanumeric char…and as there’s no floating public ip support in opennebula, VM remote access seems impossible without some kind of vpn
First, let’s hope someone can just tell you why it’s not using the patched novnc now.
I hope “opennebula-services” included sunstone
maybe this helps you:
There’s something I want to do, but didn’t have time to.
But I already have it in my mind. So here you go.
You can make iptables (or ebtables?) rules for the VNC port.
So, you get a VM with ID one-123, VNC port will be, idk, 10123 I think. IP from subnet will be 192.168.22.10
I wanna make a rule on all hosts that redirects as follows
traffic to dst IP 192.168.22.10 port 5900 will go to CURRENT HOST:10123
That way you can have direct vnc via the vm’s allocated IP address.
I generally want to have that as a feature in all my setups, but it’s on the backlog for me
There isn’t a good reason. Last time we checked novnc’s github they were still trying to find a solution, and I guess we just gave a low priority to this since there wasn’t much we could do. The last novnc release, and the patched version you mention, are not so old.
I gave #4304 a higher priority to consider these vnc issues.
we just noticed the Alt-Gr key on german keymaps is also not workable.
It seems this bug is where they track the issue and it seems there’s some patches that fix it.
Thanks for acknowledging this NoVNC bug and trying to fix it
As i don’t expect of course any ETA for the 5.4 release, would it be possible to outline the basic steps one would take in order to incorporate the NoVNC 0.5.1 fork please
I tried to do Opennebula NoVNC & non-us keyboard layout support but i guess that was to naive