I have a problem with the keyboard mapping in virtualbox guests. 

A number of keys show no action at all or turn out wrong symbols and changing the keyboard layout settings in the guest does not fix it.
Both the host and the guest run in 64 Bit.
The problem occurrs both in windows and linux guests.
On the host I tried Debian 7 with XFCE, Trinity and LXDE and I checked both the virtualbox 4.1 that comes with the distro as well as the current 4.2 installed from the wheezy backports.
I started all new then, with centos 6.4, Gnome desktop. Same issue appeared with virtualbox 4.2 installed from the virtualbox.repo
This is on a remote server which I access through vnc (tightvnc on debian and tigervnc on centos, local client is KRDC)
 
I have a German keyboard layout but I prefer to have the box run in English.
 
On centos 
cat /etc/sysconfig/keyboard
 
KEYTABLE="de"
MODEL="pc105"
LAYOUT="de"
KEYBOARDTYPE="pc"
 
LANG=en_US.UTF-8
 
All is well accessing the machine via ssh, yz at the right places, umlauts and all the symbols at the right place and available. 
All is well still accessing the host through vnc. I open Gedit and doing the same tests as above there is no problem.
In the guest however testing with a linux mint live cd, while zy still have the correct place some keys show no activity, including the key right of the P (udiaeresis Udiaeresis) and the keys right of L that should give odiaeresis and adiaeresis. The key to the left of the 1 and the key to the right of the 0 show no action. 
Other keys including the shift values of 3,7,0 and the symbol-keys on the right side have wrong output.
 
On the linux mint guest I checked the key codes with xev and those keys that show no activity apparently do not evoke a key event when hit. I can type üöäß as long as I want in the guest and xev wont output a single line.
 
Going back to the linux host xev running there outputs:
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13158645, (431,15), root:(433,68),
state 0x2000, keycode 219 (keysym 0xfc, udiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 bc) "ü"
XmbLookupString gives 2 bytes: (c3 bc) "ü"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13158781, (431,15), root:(433,68),
state 0x2000, keycode 219 (keysym 0xfc, udiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 bc) "ü"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13171357, (431,15), root:(433,68),
state 0x2000, keycode 255 (keysym 0xf6, odiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 b6) "ö"
XmbLookupString gives 2 bytes: (c3 b6) "ö"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13171481, (431,15), root:(433,68),
state 0x2000, keycode 255 (keysym 0xf6, odiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 b6) "ö"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13174995, (431,15), root:(433,68),
state 0x2000, keycode 254 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 a4) "ä"
XmbLookupString gives 2 bytes: (c3 a4) "ä"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13175522, (431,15), root:(433,68),
state 0x2000, keycode 254 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 a4) "ä"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13179885, (431,15), root:(433,68),
state 0x2000, keycode 253 (keysym 0xdf, ssharp), same_screen YES,
XLookupString gives 2 bytes: (c3 9f) "ß"
XmbLookupString gives 2 bytes: (c3 9f) "ß"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13180045, (431,15), root:(433,68),
state 0x2000, keycode 253 (keysym 0xdf, ssharp), same_screen YES,
XLookupString gives 2 bytes: (c3 9f) "ß"
XFilterEvent returns: False
 
=================================
 
So I got it working in the end. There was a bug discussion on virtualbox with helpful info about the way virtualbox handles keyboard input:

I will quickly sumarise how we handle keyboard translation on X11 hosts. In fact we have two algorithms for doing this. The first one, which is the preferred one, is to try to determine whether one of the two standard X.Org PC mappings is in use (kbd or evdev). We do this by checking the keycodes of certain keys that are not likely to vary - like the left side modifier keys, tab, the first eight function keys - and seeing if they match one of the well-known mappings (and we do check for swapped ctrl and caps lock). If they do, we use that mapping, but certain custom keyboard layouts, like Neo and probably like your Dvorak layout, defeat this.

The second algorithm originally came from Wine, although a lot of work has gone into it since then. It works by reading the symbols attached to each keycode and comparing them to standard national layouts, and working back from there to the keyboard mapping. This is needed in particular for Sunray and I believe for X over ssh and VNC (although I should probably add Sunray to the standard layouts).

So this confirmed my suspicion that virtualbox performed some weird voodoo based on what it sees as the keyboard settings. And while all looked well judging from typing on the machine, both in a ssh shell or via vnc and X, I found rather strange tables with Xmodmap -pke . 
I created a valid xmodmap on my desktop box, shortened it to only contain those keys I actually need and use and put that into a file on the remote machine. 
I edited the ~/.vnc/xstartup script of the user who runs the vnc server to include the line 
xmodmap custom-modmap
at the top. And that made the difference.

I will not pretend to understand how things actually work together, my desktop, the remote machine, the xmodmap all use and are set to a German keyboard and still virtualBox now starts and presents an English keyboard to the guest machines. But this is something the guests are happy to remap to German and at least each keypress results in a key event now.

 Google findet ein Installations-ISO für Windwos 2008 R2 als Trial bei MS, auch eine Sharepoint2010-Installation als Trial. Zum Download muss man sich mit einer MS-ID registrieren, an die da zugehörige email-Adresse gehen dann auch mails mit Produktkeys. Die braucht man.

Neue VM anlegen, üppige HD zuteilen, üppig Ram (4GB, immer noch knapp), mit dem ISO als CD-Image starten. Erstinstallation geht erstaunlich schnell, erstes Update bei bei 81% ewig hängen bis ich merke, dass hinter dem "Initial Steps"-Fenster eine Dialogbox "IE9 installieren" versteckt sitzt. Nein. Restliche Updates, reboot, restliche Updates, reboot.
Statische IP zuteilen, Installations-Ratgeber und Hinweise ergoogeln.
Nach der Anleitung Server roles und Features installieren. Reboot. 
Sharepointserver.exe in die vm kopieren (aus SMB mag sie nicht starten), Prerequisites Installieren, (will gleich erst mal einen Reboot). Den Product Key aus der Download-Mail eingeben (man hat vier zur Auswahl, habe mal den ersten genommen).

Sharepoint-Install will wissen, ob ich standalone oder eine Farm anlegen will. Standalone reicht mir erst einmal.
Nach der Installation startet ein Configuration Wizard, fragt, ob er ggf Dienste restarten darf (ja). Zeit für eine Tasse Kaffee.

Und dann startet tatsächlich Sharepoint server. Grottenlahm, wie zu erwarten war. Mit einem SP auf Port 80 und der Sharepoint Central Administration auf Port 6531.


 

Arch Linux und VirtualBox

Monday, September 24. 2012

 Mal eine Nase in Arch Linux gesteckt und eine vm (unter Virtual Box 4.1.22) damit angelegt. Der erste Schritt der Installation klingt vertraut, man lädt und startet ein Live-Image. Nur, wenn man sich jetzt so was wie Mint vorgestellt hat, grafische Oberfläche und ein freundlicher Button "Installiere mich" - wird man sich etwas die Augen reiben. das Live Image startet (sehr flink!) in eine Konsole und der Rest geht zu Fuß nach den Steps des Beginners Guide. Bei der Suche nach Installationspaketen hilft www.archlinux.org/packages/

Die vm, die per default erstmal mit der "Intel Pro/1000 MT Desktop" Nic und NAT als Netzwerkeinstellung eingerichtet war, hatte ich wie üblich ein den Modus Netwerkbrücke / Bridged Networking" umgestellt, damit die vm von anderen rechnern im Lan erreichbar ist und IPv6 gleich geht. So, und nun bekam ich super lahmen Netwerktransfer. 5-10 KiB/sec, in Spitzen auch mal 15 KiB/s - ging gar nicht. Selbst im laufenden Betrieb zuück nach NAT wechseln, dem GastOS 2 min Zeit zum umstellen geben und der Trnfer sprang auf das 100- bis 300fache.

Googlen auf "arch linux virtualbox slow" ergab nicht viel, verstreute Ratschläge, den hostname in /etc/hosts einzutragen. Meine Massnahmen waren:
- hostname als fqdn setzen
- hostname in /etc/hosts eintragen
- in VBox als Netzwerk-Hardware auf virtio-net wechseln
Die ersten beiden sind ja ohnehin Teil der Installation und änderten auch nichts an dem Problem, der Wechsel auf das virtio - Netzwerk machte dagegen den grossen Unterschied aus. Ich habe später die verschiedenen Netzwerk-Karten der Reihe nach ausprobiert und alle drei Intel-Varianten lieferten die gleiche, schneckenlahme Performance.

copy/paste der Zwischenablage zwischen Host und Guest funktioniert noch nicht, ansonsten unauffällig.


update 3.11.2012:
insgesamt hat mir arch linux bei dem test so gut gefallen, dass ich wenig spaeter auch auf dem host, meinem normalen Arbeitsrechner, auf  Arch umbestiegen bin und damit derzeit recht zufrieden bin. 

Squeeze mit aktuellerem Kernel

Monday, October 24. 2011

Anstoss der Unrast sind die heftigen Performance-Einbrüche meines Rechners während der regelmässigen incrementiellen Backups auf eine externe USB-Festplatte. Die ist wirklich nicht besonders schnell, hdparm -t ermittelt 30 MB in  3.09 seconds =   9.72 MB/sec. Mein HTC Desire ist da mit bis zu 14 MB/sec merklich schneller.

Das das Backup relativ langsam geschrieben wird ist aber an sich gar kein Problem. Wirklich nervend ist, dass die CPU sich dabei mit 80, 90% wait states eindeckt und kaum noch etwas anderes erledigen mag als, auf die lahme Platte zu warten. Auf der Suche nach möglichen Auswegen stiess ich auf Hinweise, dass Linux ab 2.6.37 mit solchen Situationen besser umgehen könne. Squeeze hat 2.6.32. Einen Versuch wär's wert.

Woher einen aktuelleren Kernel nehmen? Backports (hilfreich bei der Auswahl von Paketen), und eine schon brauchbare Anleitung für die konkreten Schritte fand sich auch bald, brauchte aber dann doch noch ein paar Änderungen und Ergänzungen.

- es schadet nicht, ein aktuelles Backup von /boot und /etc zu haben...
- nano /etc/apt/sources.list
- dort unten diesen Eintrag anfügen: 
  deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free
- apt-get update
- und jetzt installieren:
   apt-get install -t squeeze-backports linux-image-2.6-amd64

Der install macht auch ein update der Grub-Konfiguration und fügt für den neuen Kernel oben auf der Liste zwei Einträge ein. Wenn nicht alles so geht, wie man gehofft hat, kann man im Grub-Menü nach unten wandern und den bisherigen Kernel booten, das ist die dritte Zeile im Menü.
Klappte soweit ganz gut, ein paar Sachen waren aber zu erledigen. So kam beim Install ein Hinweis auf fehlende (non-free) Firmware, die für diesen Rechner mit
apt-get install -t squeeze-backports firmware-realtek
kam. Weiter monierte der install schon:

dkms: running auto installation service for kernel 2.6.39-bpo.2-amd64:
      vboxhost (4.1.4)...failed.
      nvidia (195.36.31)...failed.

dkms: WARNING: linux headers are missing, which may explain the above failures.
      please install the linux-headers-2.6.39-bpo.2-amd64 package to fix this.

Wirklich landete ich nach dem ersten boot des neuen Kernels auf der Konsole, mangels Grafiktreiber. Google fand mir diese Anleitung, NVidia-Treiber auf dem backported Kernel zu nutzen. In der bash_history hat dieser Schritt solche Spur hinterlassen (das shell script nvidia_heilen.sh entspricht dem auf obiger seite gelistetem)

apt-get install -t squeeze-backports dkms nvidia-kernel-dkms
dpkg-reconfigure nvidia-kernel-dkms
grep -ie error /var/lib/dkms/nvidia/195.36.31/build/make.log
cd /usr/local/src
mkdir backportkernel
cd backportkernel/
nano nvidia_heilen.sh
chmod 755 nvidia_heilen.sh
./nvidia_heilen.sh
apt-get install -y nvidia-glx
apt-get install -y nvidia-glx-ia32
apt-get install -y nvidia-xconfig nvidia-settings
reboot

Nun lande ich wieder auf dem grafischen Desktop und nicht nur der nvidia-Treiber sondern auch der ebenfalls monierte vboxhost sind geheilt. Bleibt vmware. Hier die hilfreiche Webseite (leider ist sie jetzt, beim schreiben dieser Zeilen, nicht verfügbar). Infos und Beschreibung treffen, aber bei mir klappte es auch mit dem Patch nicht. Letztlich half der Link zu den gepatchten Sourcen. Der Vmware-Player (3) baute sich seine Module, die liefen aber erst nach einem reboot.

Fein, damit war das Update gelungen - hat es auch was gebracht? Sieht recht gut aus, top zeigt die wa während der rsync-Läufe zwischen 25 und 30%. Und gefühlt ist das Problem damit bereinigt.

Update:
Für die Aktion etwas zu spät stieß ich auf  smxi/sgfxi/svmi, eine Familie von Scripten, die sich ganz dem Kernel-Update und der Kompilierung von Grafik Modulen und Modulen für vmbox und vmware widmen und die Sache um einiges leichter machen...

Ram und Leistung

Friday, October 21. 2011

Manche Hardware kann mehr, als in der Beschreibung steht. Beispiel: mein Mainboard MSI P41-C31. Im Manual steht eindeutig, dass das Board max. 4GB DDR3 Ram unterstützt. Was mir, mit reichlichem Einsatz von vmware und virtualBox (und der Gewohnheit, viele viele Tabs in Google Chrome und Opera nebeneinander offen zu halten) unter Linux deutlich eng wurde. Ich habe aus Anwendersicht klar den Eindruck, dass Windows (2k - 7) mit knappem Ram und virtuellem Speicher besser umzugehen weiss als Linux, aber das nur nebenbei. 
Als ich mal wieder unbedacht eine vm öffnend Viertelstundenlang meinem Kistchen beim Swappen zuschauen durfte, kam der Entschluss: anderes Board und mehr ram rein. Das Ram konnte ich direkt mitnehmen, das ausgesuchte Board steht immer noch aus. Einfach mal zur Probe die 2x4GB TEAM Elite CL9 PC3-10600 KIT eingesteckt, und zu meiner Verwunderung bootete die Kiste ohne einen Mucks. OK, dass hätte ich ruhig schon etwas früher versuchen können.

Aber natürlich kommt noch ein "Aber". Denn bald fiel auf, dass die Kiste doch ziemlich laut wurde, der Prozessor-Lüfter ging auf volle Drehzahl. Deckel auf und die Wärme der beiden  Riegel leuchtete mir förmlich entgegen, für sie werde ich wohl einen Gehäuselüfter installieren müssen. Der Sellingpoint "Aluminiumschienen zur besseren Wärmeabfuhr" des Team Elite-Ram stand da in anderem Licht als zuvor.

Für mich eine Neuigkeit, ich hatte die Leistungsaufnahme des Ram bislang immer als vernachlässigenbare Größe eingeschätzt,  (wie etwa auch der Energierechner es tut). Netzseitige Messergebnisse an einem Voltcraft Energy Check 3000 sehen 1-2 Watt Mehrverbrauch mit 8 statt 4GB Ram. Nicht viel, trotzdem werden die Dinger heiß.

Das war der Anlass, die zuvor nicht recht konfigurierten Temperatur-Sensoren einzurichten, lm-sensors war schon installiert aber der zweite Schritt war unterblieben.  Dabei half mir "Monitoring your hardware's temperature" weiter. KDE 4 brauchte anschliessend noch einen Neustart des Desktop bis es die Werte anzeigen mochte, die xsensors oder, von der Kommandozeile, sensors schon gleich verriet.

Ein Bios-Update, Streifzug durch die Bios-Settings und Lüfterbastelei später läuft alles kühl und ruhig.

(Page 1 of 2, totaling 7 entries) » next page