VirtualBox auf den Clients

2017: Planung VM für XP und Windows7

• VDI-Dateien sind groß (XP: 3GB Win7: 20-30GB), sie sollen per Torrent verteilt werden
• für das Verteilen wird nicht mehr LINBO benutzt, so dass das Image nicht mehr die Endung cloop benötigt
• Management-Scripte können auf dem Server liegen (NFS-mounts auf den Clients vorhanden)
• auf den Clients:
  • /dev/sda2 ist obsolet -> entfernen
  • neue Struktur: /dev/sda1 (Ubuntu) /dev/sda2 (swap) /dev/sda3 (cache)
  • kepler--ctorrents als systemd-Dienst starten
    • stellt cloops aus der start.conf bereit (ctorrent), so dass ein Sync auch bei laufenden Ubuntu-Cieents genügend Seeder findet
    • stellt vdi-Images bereit, Verteilung per Zuordnung in einem Verzeichnis auf dem Server, lädt die vdi erstmal herunter in den Cache
    • Mounten des Caches nach /cache per fstab (RW ist OK?)
    • das VDI in das allgemeine Image zu packen, würde den Sync-Vorgang unnötig in die Länge ziehen
    • Snapshots nach /tmp/ (wie im Experiment CLOOP erprobt)
• Beachten: Virtualbox merkt sich in den Einstellungen den absoluten Pfad (bei den SuS leider mit der Klasse, die sich jährlich ändert) - Befehl heraussuchen, der das ändert oder XML-patchen

2017: Abschlussbericht zum Experiment CLOOP

Das Verfahren hat sich nicht bewährt, da zu viel schieflaufen kann! Der Test hat aber viele Erkenntnisse geliefert, wie VirtualBox auf den Clients managebar wird.

• zunächst war eine eigene 6GB-Partition auf den Clients vorgesehen (/dev/sda2 gemountet nach /usr/share/virtualbox-vdi), die LINBO gesynct hat,

enthalten war das VDI-File und die Starterscripte. Auf der Partition lagerten auch die Snapshots, was aber dazu führte, dass gerne mal die 6GB volliefen

• Umstellung im Schülernetz:
  • /dev/sda2 nicht mehr mounten
  • LINBO stellt virtual-XP_S.cloop im Cache (/dev/sda4) bereit, manchmal tut LINBO das aber nicht, kepler--ctorrent korrigiert den Fehler und stellt einen Torrent-Seeder bereit
  • kepler--cloop lädt das cloop-Kernelmodul und mounted das cloop nach /usr/share/virtualbox-vdi - Problem: Bei neuen Kernelreleases muss das Modul neu für DKMS bereitgestellt werden - manchmal macht DKMS komische Sachen und das Kernelmodul funktioniert nicht
  • rc.local hat auf der mehrzahl der Clients irgendwelche Timing-Probleme, so dass das cloop nicht gemounted wird - nachträglich auf den Maschinen rc.local starten behebt das Problem fast immer.

Virtuelle Maschine mit Speicherabbild starten

VirtualBox aus einem Speicherabbild zu starten hat sich nicht bewährt!

Einrichten der VM für die Kollegen

Obsolet - in der Zeit, als wir LTSP im Einsatz hatten, musste die Einrichtung auf dem Server stattfinden, das komplette Management wird aktuell auf den Clients gemacht.

Virtuelle Maschine verändern

Obsolet - in der Zeit, als wir LTSP im Einsatz hatten, musste das Image auf die Server verteilt werden. Aktuell erfolgt das Management auf den Clients.

Speicherabbild der Virtuellen Maschine erzeugen

Obsolet - siehe oben

Windows in der Virtual Box

Obsolet - LTSP nicht mehr im Einsatz

Die Konfiguration der VM sichern und zurückspielen

Wenn man aus der VM die virtuellen Festplatten entfernt, so kann man über das Menü sehr effizient und schnell die gesamte Konfiguration in ein .OVA-File packen. Dieses kann man ganz leicht wieder (z.B. bei den Kollegen) zurücksichern, entweder auch in der GUI oder per Script (setup-virtualwindows):

  vboxmanage <VMName> <Pfad>/<Name>.ova

ACHTUNG: vor dem Sichern das Festplattenabbild entfernen, sonst wird die Datei sehr groß!

Teilen des gleichen Snapshots

In unserem Setup werden viele Nutzer gleichzeitig auf die gleiche virtuelle Windows-Installation zugreifen.

Frage

Können sich mehrere Nutzer gleichzeitig das gleiche Windows-Image teilen?

Idee

Das kann wohl nur gehen, wenn nicht alle Nutzer gleichzeitig das selbe Image beschreiben können. Sie dürfen zwar gemeinsam lesen, müssen jedoch in verschiedene Dateien schreiben. Unsere Hoffnung ist, dass dies passiert, wenn man in VirtualBox einen "Snapshot" erstellt und den startet. Dann sollten alle Änderungen in ein Differenzplattenimage gehen.

Wahl des passenden Medientyps

In der VirtualBox-Konfig kann man anklicken, dass eine virtuelle Platte "unveränderlich" sein soll (Medieneigenschaften).

Kapitel 5.4 und 5.5 des ziemlich gut geschriebenen VirtualBox-Manuals enthalten die relevanten Informationen:

• ​5 Virtual Storage
  • ​5.4 Special Image Write Modes
  • ​5.5 Differencing Images

Demnach sind die Modi, die für uns in Frage kommen

• "immutable" - das funktioniert und hat sich bewährt
• "multi-attach mode"
• oder eventuell auch "shareable".

Medientyp: unveränderlich (immutable)

Ein wichtiger Hinweis steht da, wie man ein "immutable" Image richtig erstellt:

1. Zuerst als "normales" Image installieren, bis alles in dem Zustand ist, in dem man es einfrieren möchte.
2. Dann die virtuelle Maschine abschalten(!)
3. Dann das Image als "immutable" kennzeichen

Danach sollte jeder Nutzer bei jedem Start der virtuellen Maschine wieder das eingefrorene Image erhalten, das Differenzabbild wird automatisch verworfen**

Das scheint doch genau das zu sein, was wir wollen, oder? Funktioniert aber nicht, wenn das Image von einer laufenden Maschine eingefroren wurde (siehe Manual).

Das bedeutet, dass die Nutzer dann auch gerne im Windows als Administrator angemeldet sein können, dann muss man im Windows nicht auch noch Rechteverwaltung machen.

Medientyp: multi-attach mode

Beim Medientyp "multi-attach mode" können mehrere VM konkurrierend auf ein Image zugreifen. Jede Maschine erhält ihr Differenzabbild (im Homeverzeichnis des Users). Das Differenzabbild überlebt zwischen verschiedenen Aufrufen.

Medientyp: shareable

Der Medientyp "shareable" erlaubt es mehreren laufenden virtuellen Maschinen gleichzeitig auf das gleiche Image zuzugreifen. Die Maschinen erhalten kein Differenzabbild, sondern greifen wirklich alle gleichzeitig auf die Datei zu, wie auf einem normalen Multiuser-Betriebssystem. (Kommt Windows damit klar?)

Anmeldung/Zugriff auf die home- und share-Verzeichnisse

Auf den Clients sind die HomeVZ gemountet, es muss nur ein Share home in VirtualBox eingerichtet und mit Eigene Dateien verbunden werden.

Notizen RAL Linux 6.2.2013

Mitglied in der Gruppe vboxusers

Nutzer müssen in der Gruppe vboxusers sein, damit sie Virtualbox ausführen dürfen. Das lässt sich bequem über die /etc/security/group.conf machen, oder über den LDAP-Mechanismus, den wir für die Gruppe video verwenden.

Einrichten des Windows-Images

• (Das Windows-Image sollte so weit wie möglich abgespeckt werden.)
• Es braucht nur einen Nutzer zu geben, (mit Administratorrechten?)
• Das Homeverzeichnis des Nutzers sollte als "shared folder" eingebunden werden und dann unter "Eigene Dateien" erscheinen.
• Auslagerungsdatei abstellen! Stattdessen der VM mehr virtuellen Speicher geben, dann dann macht der Server wenn nötig das Swappen.
• Die komische Systemwiederherstellung von Windows abstellen, die alle Änderungen mitverfolgt.

GuestAdditions für Windows

Für 3d-Beschleunigung nötig. Können nur im abgesicherten Modus installiert werden (beim Windows-Start F( drücken).

Umsetzung

Das ganze lässt sich umsetzen, wie bei unserem LtspWine.

• die "immutable" Platte mit der Windows-Installation liegt auf dem Server und wird nie herumkompiert
• das Differenzabbild des Nutzers liegt lokal und wird jedesmal vorher/nachher gelöscht
• Die Konfigurationen in ~/.VirtualBox werden entweder über den Skeleton-Mechanismus verteilt, oder über rsync gesynct wie bei LtspWine. Jedenfalls müssen diese Dateien dem Nutzer gehören.

Alternative, die mir sinnvoller erscheint:

• Das vdi-File liegt irgendwo lesbar
• Die Nutzer bekommen per Skript die Virtuelle Maschine eingerichtet. Das geht mit dem vboxmanage-Befehl:

  vboxmanage createvm --name XP --ostype WindowsXP --register
  vboxmanage modifyvm XP --memory 512
  vboxmanage modifyvm XP --vram 32
  vboxmanage modifyvm XP --audio pulse
  vboxmanage storagectl XP --name IDE --add ide --bootable on
  vboxmanage storageattach XP --storagectl IDE --medium /usr/share/virtualbox-vdi/XP.vdi --mtype immutable --port 0 --device 0 --type hdd
  vboxmanage sharedfolder add XP --name home --hostpath $HOME --automount
  

• dabei sollte noch das Verzeichnis, in dem die VMs des Benutzers abgelegt werden, wo also das Differenzabbild liegt, nach /tmp oder so verschoben werden.
• Parameter noch etwas tunen, dann sollte es das gewesen sein.

Einrichten der virtuellen Maschinen

Um die virtuellen Maschinen für die Kollegen einzurichten, gibt es ein Skript.

Das Skript liegt unter scripts/setup-virtual-windows. Es muss derzeit aber auf einem LtspServer ausgeführt werden. Auf dem paedml läuft es nicht, weil es für das alte Debian kein aktuelles virtualbox gibt. (Ich hab nur in den APT-Quellen nachgesehen, vielleicht kann man das virtualbox-Paket direkt von Oracle installieren, das wollte ich auf dem paedml aber nicht machen.)

Verwendung:

linadmin@ltsp118:~$ setup-virtual-windows [uid]

Wird eine user id angegeben, wird die VM für diesen Nutzer eingerichtet. Wird das Skript ohne user id aufgerufen, legt es die VM für alle Lehrer an.

Administrieren des Windows-Images

Das geteilte XP-Image liegt auf allen LtspServern unter /usr/share/virtualbox-vdi/XP.vdi. Die VM der normalen Nutzer greift darauf im "immutable"-Modus zu, mit Differenzbildern in den Homeverzeichnissen.

Der Nutzer linadmin hat dagegen eine virtuelle Maschine, die schreibend auf das XP-Image zugreift. Das Administrieren läuft also folgendermaßen ab:

1. Als linadmin auf einem LtspServer einloggen
2. Vorsichtshalber eine Sicherungskopie der aktuellen Windows-Installation machen:

   linadmin@ltsp118:~$ cp /usr/share/virtualbox-vdi/XP.vdi /usr/share/virtualbox-vdi/XP.vdi--<Datum>
   

3. Virtualbox starten und Maschine "XP-schreibbar" starten
4. Änderungen vornehmen
5. Virtuelle Maschine und Virtualbox beenden
6. Das neue Image auf alle LtspServer verteilen:

   linadmin@ltsp118:~$ sudo scripts/rsync-to-all-ltsp-servers /usr/share/virtualbox-vdi/XP.vdi
   

Zur Konfiguration der virtuellen Maschinen

Einige Hinweise zu empfohlenen Konfiguratiponsoptionen der VM:

SATA-Controller

Windows XP kann von sich aus nur von einem IDE-Laufwerk booten. Auch in VirtualBox ist die Emulation eines SATA-Laufwerks aber efizienter als die eines IDE-Laufwerks.

SATA-Treiber können entweder vor dem Windows-Setup per Funktionstaste installiert werden, oder nach der fertigen Installation nachinstalliert werden. Danach kann das VirtualBox-Image vom IDE- an den SATA-Controller gehängt werden.

VirtualBox emuliert einen Intel SATA-Controller. Den nötigen Treiber gibt es hier: ​http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=2101&DwnldID=17882&lang=eng

Storage --> Us host I/O cache

Sollte auf Linux-Hosts wohl besser abgeschaltet sein, siehe

• ​http://www.virtualbox.org/manual/ch05.html#iocaching

  Disk image files tend to be very large. Caching them can therefore quickly use up the entire host OS cache. Depending on the efficiency of the host OS caching, this may slow down the host immensely, especially if several VMs run at the same time. For example, on Linux hosts, host caching may result in Linux delaying all writes until the host cache is nearly full and then writing out all these changes at once, possibly stalling VM execution for minutes. This can result in I/O errors in the guest as I/O requests time out there.

Swap

Eine spontane Idee war, die Swap-Datei in den Gast-VM komplett zu deaktivieren und ihnen stattdessen viel virtuellen Speicher zu geben. Dann würde der Host das gesamte Caching übernehmen.

Es ist jedoch unklar, ob das vorteilhaft ist, weil der Host keinerlei Wissen hat, welchen Teil der VM er ausswappen soll. Der Gast hingegen würde gar nicht merken, dass Speicher knapp ist, und so weiterlaufen, als sei ständig genug Speicher vorhanden. Insgesamt könnte das die Gast-Performance sehr negativ beeinflussen.

Aus Performance-Sicht ist es vermutlich ein besserer Kompromiss, die übliche Windows-Swapdatei auch im Gast zu aktivieren.

Achtung

Da die Differenzimages der VM aber in den Homeverzeichnissen unserer Nutzer liegen, würde die Auslagerungsdatei in die Homeverzeichnisse schreiben, die über NFS angebunden sind. Das ist wohl eine schlechte Idee!

Abhilfe könnte es hier schaffen, die Auslagerungsdatei auf ein eigenes virtuelles Laufwerk zu legen, das lokal auf den LtspServern liegt. Wenn wir das lösen, können wir allerdings auch gleich die ganzen Differenzimages dahin legen...

Befehle von außen an eine laufende VM senden

Damit das unter XP tut, muss man eine Gruppenrichtlinie anpassen (siehe ​https://www.virtualbox.org/manual/ch14.html):

• gpedit.msc in der laufenden VM ausführen
• Navigieren zu:

Computer Konfiguration -> Windows Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen --->>> Wert auf Deaktiviert setzen: Konten: lokale Kontenverwendung von leeren Kennwörten auf Konsolenanmeldung beschränken

Danach kann mit dem Befehl

   vboxmanage guestcontrol "XP" execute --image "C:\\Pfad zur Datei" --username "Nutzer" --wait-stdout

jedes beliebige Programm in der VM gestartet werden

VirtualBox mit vdfuse und reged

vdfuse existiert nicht mehr ab Ubuntu 16.04 - Ersatz: qemu-nbd

• reged das ist ein Linux-Regedit
  • chntpw -i /mnt/WINDOWS/system32/config/system
• virtualbox-fuse damit kann eine virtuelle HDD (.vdi) gemountet werden:
  • vdfuse -a -f /path-to-vdi-file /mnt
  • mount -o loop /mnt/Parition1 /mountpoint

Damit ist es möglich, das VDI vor dem Booten zu mounten und per chntpw den Rechnername in die Registry zu patchen