Schon mal versucht mit einer 64-Bit-Version von Windows-7 via ODBC auf eine Access-Datenbank zuzugreifen? Tja ... so wie es in diesem Beitrag von Thomas Schiffler erklärt wird, geht das nur über die 32-Bit-ODBC-Treibermanager (Odbcad32.exe) den man auch erst mal finden muss. Großartiger Beitrag! Danke an Thomas Schiffler.

Als Setup hatte ich jeweils eine LVM-basierende Installation mit Verschlüsselung verwendet. Dabei wird "nur" der Bereich /boot unverschlüsselt auf der Festplatte abgelegt - das ganze restliche Dateisystem ist verschlüsselt. Fedora frägt beim Booten den Passphrase in einem grafischen Bildschirm - war prima aussieht. Leider konnte ich aber nicht feststellen wie das eigentich gemacht wird - bei openSUSE bleibt es an der Stelle nämlich erst mal beim Fallback auf den Textbildschirm.

Der enthaltene WLAN-Chipsatz (Broadcom BCM4313) wurde bei beiden Distributionen von Haus aus nicht unterstützt und es war Nacharbeit notwendig um Wireless ins Netz zu kommen.

• Bei openSUSE 12.1 habe ich zuerst die gleiche Lösung wie bei 11.4 versucht (siehe unten), scheiterte aber damit. Eigentlich soll der installierte Kernel in der Version 3.1.0 diesen Chipsatz ja auch ohne weiteren Treiber unterstützen - tat es hier aber erst mal nicht. Die Lösung brachte dann das Paket kernel-firmware. Dass openSUSE dieses Paket nicht gleich von Haus aus installiert, vor allem wenn schon diese WLAN-Chipsatz gefunden wurde, halte ich für einen bösen Bug. Schade! Ab Kernel 3.2 müsste dann dieser Treiber wieder durch den Original-Brcm80211-Treiber (Brcmsmac und Brcmfmac) von Broadcom abgelöst werden.
• Bei openSUSE 11.4 wurden vom Packman-Repository die Pakete broadcom-wl und broadcom-wl-kmp-desktop installiert. Für openSUSE 11.4 gilt, dass durch die Verwendung dieses Treibers von Broadcom der Kerneltreiber b43 erst mal auf der Blacklist landet. Mit dem B43-Treiber unter einem 3.0.1-Kernel (openSUSE-Tumbleweed) war das WLAN aber auch leider erst mal nicht funktionsfähig. Weiteres zum Thema ... .
• Bei Fedora 15 fand sich der Treiber im RPM-Fusion-Repository

Richtig ärgerlich wurde es erst beim Reboot des Systems. Während das Runterfahren problemlos klappt, hängt sich das System beim Reboot komplett auf. Ein Bugreport bei Ubuntu brachte die Lösung in Form des Kernelparameters reboot=pci der dann bis hin zu openSUSE 12.1 (neueste hier beschriebene Distribution) notwendig ist.

Letzendlich blieb dann die openSUSE-12.1-Installation auf dem Gerät.

Kommandozeilen-Werkzeuge im Paket libguestfs-tools

Das Paket libguestfs-tools enthält einige Werkzeuge mit der Dateisysteme virtueller Maschinen analysiert oder verändert werden können. Insbesondere die Größenänderung einers Plattenimages und der enthaltenen Dateisysteme wird damit leicht ermöglicht. Es enthält auch Werkzeuge um Dateien in diesen Dateisystemen anzuzeigen, zu editieren, zu sichern, ... . Nachfolgend ein kurzer Überblick in dem die Anwendung einiger der Werkzeuge kurz demonstriert wird - und eine Demonstration einer Plattenimage-Größenänderung.

In diesem Zusammenhang übermittelte der Kollege mir auch die Website http://www.ilsistemista.net. Dort hat es einige sehr gute Artikel zu Performance-Unterschiede diverser Lösungen - und das mit umfangreichen Tests belegt.

Sehr geholfen hat mir z.B. diese beiden Artikel (KVM I/O slowness on RHEL 6 und KVM vs VirtualBox 4.0 on RHEL 6). Fazit für KVM in aller Kürze:

1. Unbedingt auf dem Hostrechner das Caching für die virtuellen Festplatten abschalten. Das gilt insbesondere für die zweite und alle weiteren Festplatten - bei der ersten macht es RedHat von selbst. Konnte ich prompt nachvollziehen!
2. Bei Verwendung von Dateien zur Verwendung als virtuelle Festplatte im Gastsystem sollten die Dateien komplett vorangelegt werden damit der ganze Plattenplatz schon reserviert ist. Der Virtual-Machine-Manager tut das nämlich nicht und die Performance ist dann liederlich. Da ich dem VirtManager eine LVM-Physical VG für die Gäste gegeben habe, war ich zumindest nicht in diese Falle getappt.

Aber ggf. selbst die obigen Quellen nachlesen - lohnt sich!

Für Tests mit der Netzwerkperformance eignet sich iperf zu dem es hier ein ganz brauchbares Tutorial gibt -> http://openmaniak.com/iperf.php.

Lösung: Unter http://raftaman.net/?p=995 fand ich die notwendigen Einstellungen um die virtuellen Maschinen beim Shutdown des Wirtsrechners ebenfalls wirklich Herunterzufahren, statt sie nur zu Suspenden. Die Einstellungen

ON_SHUTDOWN=shutdown
SHUTDOWN_TIMEOUT=60

sind in der Datei /etc/sysconfig/libvirt-guests vorzunehmen.

Verteilungsprobleme

Für die Leitung der Schulung ergeben sich daraus aber in der Praxis durchaus auch Nachteile. Ein ganz praktisches Problem ist die Verteilung der virtuellen Maschinen da diese im Normalfall mindestens ca. 2GB an Datenvolumen haben und damit nicht mehr "mal eben kurz" an die Teilnehmer/innen ausgeteilt werden können. Bei 2GB und 20 Teilnehmern müssen in so einem Fall nämlich 400 GB vom Schulungsserver (oder womöglich sogar vom Laptop der Schulungsleitung) über das Netz übertragen werden. Je nach Server/Netzinfrastruktur kann das eine nicht mehr zumutbare Zeit in Anspruch nehmen zumal hier neben der Netz-Infrastruktur auch die Festplatte des Verteilrechners schlapp macht.

An einem einzigen Tag also mal nebenbei 5 verschiedene Szenarien, die jeweils aus 2 virtuellen Maschinen bestehen, zu verwenden ist meist unmöglich - das sind nämlich schon mind. 800GB! Auch ein spontan am Vortag entwickeltes Szenario zu Beginn der Schulung am nächsten Morgen kurz auszuteilen - gilt u.a. auch für Prüfungen, Klassenarbeiten, ...) wird damit fast unmöglich.

Nun ... z.B. um mit diesem Utility feststellen zu können ob ein bestimmter Rechner bzw. eine IP-Adresse im LAN an ist oder nicht. Dafür ist zwar eigentlich ping das übliche Utility aber falls der betreffende Rechner ICMP-Echo-Requests über eine Firewall sperrt erhält man keine Antwort mehr. Diese Firewall-Einstellung ist z.B. bei Windows XP mit Service-Pack 2 und allen neueren Versionen von Windows die Default-Einstellung.