Gibt es so eine Virtualisierungslösung? GRUB für VM´s?

[Alternativende]

Hallo zusammen,
mir ist eben eine Idee für die Neuausstattung unseres Schulungsraums im nächsten Jahr gekommen.

Gibt es eine Linuxdistro oder ein Programm das bootet und mir wie beim Dualboot zwei oder mehr Betriebssysteme zur Startauswahl anbietet, nur dass diese Betriebssysteme eigentlich nur virtuelle Maschinen sind?

Den Vorteil den ich in einer solchen Lösung sehe ist das ich ganz einfach Images ersetzen könnte wenn jemand etwas verkonfiguriert oä..

Also ich suche im Prinzip ein Grub was VM´s startet.

Hoffe das ist irgendwie verständlich erklärt.

Danke!

[MartinV]

Ich sehe diese Möglichkeit:

Nach dem Hochfahren des Rechners wird kein Desktop oder Display Manager gestartet, stattdessen wird z.B. mit dialog ein Auswahlmenü angeboten, in dem die VMs aufgelistet sind.
Die gewählte VM wird z.B. mit 'VBoxSDL --startvm VMNAME' gestartet, evtl. zusammen mit einem minimalistischen Fenstermanager. Bei Beenden der VM fährt der Computer herunter, oder kehrt zum Dialog zurück.

Bleibt die Frage nach dem Login im Hauptsystem. Es könnte einen weitmöglichst rechtlosen Benutzer ohne Paßwortabfrage geben, der nichts darf außer eine VM zu starten, so daß jeder problemlos auf die VMs zugreifen kann, ohne anderen Schaden anzurichten.
Oder es werden verschiedene Benutzer eingerichtet, von denen jeder davon seine individuelle VM-Sammlung vorgesetzt bekommt, was sinnvoll ist, wenn Schüler über längere Zeit mit einer persönlichen und veränderlichen VM arbeiten sollen.

[DeletedUserReAsG]

Den Vorteil den ich in einer solchen Lösung sehe ist das ich ganz einfach Images ersetzen könnte wenn jemand etwas verkonfiguriert oä..

Ich verstehe das so, dass dein Bootloader statt eines normalen Systemes eine VM mit einem System booten soll? In dem Fall würde sich zumindest für diesen Punkt nix ändern: ob du nun ein kaputtkonfiguriertes, direkt laufendes System durch ein Image eines sauberen Systemes ersetzt, oder ein kaputtkonfiguriertes, in einer VM laufendes System, ist unterm Strich ziemlich egal.

Ansonsten könnte Xen in die Richtung gehen, die du haben willst?

[Alternativende]

Die Gäste wären wohl im wesentlichen Windowsmaschinen. Da kommt mir ein anderes Problem in dem Zusammenhang in den Sinn. Da Windows zwingend unterschiedliche Hostnamen benötigt müsste das "Master Image Windows" nicht Mitglied der Domäne sein. Dies würde dann auch bedeuten das ich nicht alles an Software vorinstallieren kann.

dialog kenne ich noch gar nicht, muss ich mir mal ansehen. Wie der "Gast" aber auch das Hauptsystem runterfahren soll ist mir noch nicht klar.

[MartinV]

Es wäre gut, wenn Du genauer beschreibst, was Du erreichen willst.

Mir ist z.B. nicht klar, ob Du einzelnen Benutzern mehrere VMs zur Auswahl anbieten willst, oder ob mehrere Benutzer den gleichen Rechner nutzen sollen, von denen jeder nur eine, seine persönliche VM nutzen kann/soll.

Zudem scheint es in Deinem 2. Post darum zu gehen, mehrere VMs in einem Netzwerk zu verbinden, was neue Fragen aufwirft.

Wenn Du Dein Gesamtkonzept oder Ziel beschreibst, kann man Dir besser zielführende Vorschläge machen.

dialog kenne ich noch gar nicht, muss ich mir mal ansehen.

dialog bietet die Möglichkeit, im Terminal ein komfortables, Grub-ähnliches Menü anzubieten.

Wie der "Gast" aber auch das Hauptsystem runterfahren soll ist mir noch nicht klar.

Der Gast würde das Hauptsystem nicht selbst herunterfahren, das Hauptsystem würde nur merken, wenn der Gast beendet wird, und würde sich dann auch selbst beenden.

[heisenberg]

Also mit Xen, KVM und VirtualBox kann man so etwas schon hinbekommen. Vom Gefühl denke ich, dass das aber schon etwas Aufwand ist.

Welche Virtualisierungssoftware?
Bei VirtualBox kann man die VM gleich mit Grafikausgabe starten. Bei Xen und KVM würde man sich über VNC oder SPICE verbinden. Ich vermute mal letzteres bringt nicht so die Grafikperformance. Falls da mal HD-Videos laufen sollen würde das z. B. eine Rolle spielen.

Umgebung
Grundsätzlich heisst "Virtualisierung booten" natürlich, dass Du auf allen Rechnern erst einmal die Virtualisierungs-Host-umgebung haben musst. Ob es da was fertiges gibt, was man z. B. einfach übers Netz booten kann, weiss ich selbst nicht. Ich würde sagen, auf jedem Rechner muss ein schlankes Linux drauf, was dann eine pures X(=Grafik) startet. Anschliessend wird dann die VM bzw. der VM-Bildschirm gestartet. Bei Xen/KVM würden die VMs wahrscheinlich automatisch beim Systemstart gestartet werden und nur der Viewer wird in der Oberfläche noch gestartet. Bei VirtualBox würde die VM dann mit Grafikausgabe gestartet. Die Images liegen z. B. auf dem Netzwerk und werden via NFS lokal eingehängt. Ich vermute man kann auch nicht mehrere VM-Instanzen mit dem gleichen Image starten. Über Umwege könnte das mit btrfs - clones gehen, oder aber für jeden Rechner wird eine eigener VM-Klon erstellt, der sich vom Basis-Image ableitet(ohne das komplette Image kopieren zu müssen. Bei Virtualbox geht das).

Was das Auswählen der Images betrifft, da könnte man Bootoptionen bei Grub setzen. Die kann man dann später beim start eines eigenen Systemdienstes auslesen(/proc/cmdline) und in Abhängigkeit davon die richtige VM starten.

Was das Herunterfahren betrifft, vielleicht kann man da im Gast was scripten, das sich z. B. per SSH mittels Keys auf den Host verbindet und dort das Herunterfahren auslöst.

Was da ansonsten die Windows-spezifischen Probleme sind, weiss ich nicht. Braucht der Rechner wirklich eine eigene SID(=Eindeutige Sicherheitskennung des Windows-Computers im Netzwerk. Falls da was mit Domänennutzung ist, brauchst Du das in jedem Fall, -> Sysprep)? Braucht der Rechner wirklich einen eigenen Hostnamen? Oder funktionierts dann doch auch mit dem gleichen Hostnamen und DHCP(Gleicher Hostname wird mit Sicherheit die "Netzwerkumgebung" unter Windows brechen lassen)? Vielleicht kann man das mit Loginscripten automatisiert anpassen lassen.

Ich würde sagen mit einer unbeaufsichtigten Windowsinstallation hast Du da wahrscheinlich viel weniger Aufwand. Nicht zuletzt bedeutet die zusätzliche Virtualisierungsschicht eine weitere Quelle von möglichen Fehlerquellen, einen weiteren thematischen Bereich, in dem man sich auskennen muss.

Ob die aktuellen Windowsvarianten von der Performance her noch zufriedenstellend laufen, wenn die Images über das Netz gebootet werden, frage ich mich auch.

[Alternativende]

Danke für die Kommentare. Hintergrund der Anfrage war und ist leider auch die Lizenzpolitik. Ich darf mit unserer aktuellen Lizenz das erworbene Windows nicht auf zwei Partitionen installieren, es aber bis zu vier Mal virtualisieren.

Machbar wäre es natürlich ein schlankes Debian mit XFCE booten zu lassen und dort per Virtualbox zwei virtuelle Maschinen auf den Desktop zu legen. Hätte den Charme das das Debian auch voll nutzbar wäre.

Da es sich aber um eine voll funktionsfähige Domänenumgebung mit Exchange handelt, müssen die Rechner wohl alle eine eigene SID, Namen etc. haben, ansonsten funktioniert da so ziemlich nichts . Das bringt mich zu dem was heisenberg geschrieben hat, es wird mir höchstens möglich sein ein nacktes Windows 10 immer parat zu haben in einer Master-VM und diese dann bei Bedarf (kaputt geklickt) auszutauschen. Bewahrt mich dann aber nicht vor der Domänenintegration und der Installation der benötigten Software. Wobei letzteres meist automatisch abläuft.

@MatinV
Ich muss mehreren Benuttzern dieselbe Software anbieten und will Ihnen daher mehrere VM´s bzw. Betriebssysteme anbieten. Aber wie gesagt es können nicht alle dieselbe Maschine nutzen. Zum einen wegen der Performance und zum Anderen wegen der Domäne.

[heisenberg]

Bei den komplexen Lösungen, die hier im Raum stehen, würde ich mal vermuten, dass die paar Cent für die Windows-Lizenzen den zusätzlichen Administrationsaufwand bei weitem unterbieten.

Das mit der SID kann man schon auch weg automatisieren.

Kannst ja mal schreiben, wie Du's dann umgesetzt hast.

[r4pt0r]

Das bringt mich zu dem was heisenberg geschrieben hat, es wird mir höchstens möglich sein ein nacktes Windows 10 immer parat zu haben in einer Master-VM und diese dann bei Bedarf (kaputt geklickt) auszutauschen.

Das ist die einzigst sinnvolle art Windows egal in welcher Version zu betreiben... Hardware und Daten kann man dem OS nicht anvertrauen, speziell wenn man an den Daten hängt.
Eleganteste Variante: ZFS zvols für VMs - die können sich dann darauf austoben wie auf nem normalem blockdevice, wenn sich Windows dann wieder mal zerlegt ist ein snapshot in wenigen sekunden wiederhergestellt. Da die ZFS-Snapshots extrem "billig" sind, kann man problemlos mehrere Dutzend davon vorhalten - ich lasse VMs (smartOS) automatisch alle 15min mit 2h haltezeit snapshotten, jede Stunde mit 2 Tagen, jeden Tag mit 2 wochen und wöchentlich mit 3 monaten. Monatliche snapshots gehen dann in den longterm-zyklus auf dem Backupsystem...
Zusätzlich benötigter Platz für die Snapshots ist bei "normalen" VMs nur wenige 100MB bis einstellige GB - also zu vernachlässigen. Wiederherstellung ist ein einfaches 'vmadm shutdown <VM> && zfs rollback <snapshot> && vmadm start <VM>. Am längsten dauert das herunterfahren und starten der VM, der rollback ist in max 5sek fertig.


Windows als vorkonfiguriertes Template vorzuhalten ist ein dermaßen irrsinniger und ekelhafter aufwand und praktisch nicht zu automatisieren - zumal die Personalisierung hinterher auch zu großen Teilen manuell erfolgen muss. Ich habe angefangen so eine Lösung zu bauen - mir würden auf anhieb mehrere mittelalterliche Foltermethoden einfallen die Gebrauch von stark erhitzten Metallinstrumenten und diversen Körperöffnungen machen, die ich dem Bau/Pflegen und Ausrollen einer solchen VM Vorziehen würde...
Im grunde *muss* man das System so minimal und generisch wie möglich halten und idealerweise nur für eine oder SEHR wenige einzelanwendungen einsetzen; dann lässt sich das halbwegs per chocolatey und ansible lösen. Sobald die User anfangen in der VM rumzupfuschen und eigene Software installieren fliegt einem sowas um die Ohren. Windows-Updates sind praktisch nur per manueller installation/prüfung an einer master-VM zu handeln mit anschließened erneutem deployment der VM an die Clients. Ohne Configmanagement kann man für sowas nen Wahnsinnigen einstellen, der sich den Ganzen tag nur um rumgeklicke in den VMs kümmert (wenn man ne Nervenheilanstalt in der Nachbarschaft hat gibts dafür evtl genug Opf.. Freiwillige...).

Wenns nur um eine einzige Software geht, wäre es ggf einfacher diese per Terminalserver anzubieten - das lässt sich dann (je nach Software) ggf sogar direkt auf anderen Plattformen nutzen und man muss nur eine einzelne VM vorhalten anstatt sich nen ganzen Zoo an Windows-Clients/VMs aufzuhalsen.

[Alternativende]

Das mit den zvols klingt sehr interessant, hast Du da ein Toturial oder weitere Infos irgendwo zu? Ich habe davon bisher noch nichts gehört, aber die Möglichkeit einfach Maschinen zurücksetzen zu können ist gerade in diesem Umfeld sehr interessant.

Du würdest das ganze dann auch mit einem Debian als Unterbau betreiben, oder?

[r4pt0r]

Das mit den zvols klingt sehr interessant, hast Du da ein Toturial oder weitere Infos irgendwo zu? Ich habe davon bisher noch nichts gehört, aber die Möglichkeit einfach Maschinen zurücksetzen zu können ist gerade in diesem Umfeld sehr interessant.

Das wird durch ZFS per snapshot und rollback ermöglicht - die VM-Images müssen also auf ZFS liegen. http://www.openzfs.org ist die offizielle Seite des Projekts, das die Entwicklung von ZFS koordiniert, dort gibt es auch weiterführende Infos.
Ansonsten kann ich die beiden Bücher zu ZFS von Michael W. Lucas empfehlen - damit bekommt man das gesamte Handwerkszeug für die ZFS-Administration.

Du würdest das ganze dann auch mit einem Debian als Unterbau betreiben, oder?

Debian ist IMHO wie alle anderen systemd/Linux-Betriebssyteme mittlerweile leider ein ziemliches Schlachtfeld und weit entfernt von dem "rock-stable" Betriebssytem, das es zu Zeiten von squeeze oder wheezy war. Die ZFS-integration ist auch noch eher holprig und es gibt regelmäßig probleme nach Kernelupdates (booten!). In Produktivumgebungen laufen bei mir nur noch vereinzelt devuan-systeme, die aber nach und nach zu FreeBSD migriert werden. Ansonsten wird debian/devuan nur noch vereinzelt für (test)systeme/VMs verwendet, auf denen spezielle Anwendungen zwingend linux voraussetzen und alpine linux (in lx-zones) nicht "ausreicht".
Für Hardware-Virtualisierung (KVM) und OS-Virtualisierung (zones / lx-zones) nutze ich mittlerweile smartOS. Wenn kein eigener IP-Stack benötigt wird kommen jails auf FreeBSD-Systemen zum Einsatz. FreeBSD bzw PC-BSD/TrueOS läuft mittlerweile auch auf den meisten meiner Desktops/Notebooks.
Beide Betriebssyteme (illumos, FreeBSD) haben ZFS als Standard-Dateisystem tief integriert und viele tools stützen sich auch auf ZFS-Funktionen, das erleichtert den Alltag ungemein.

[Alternativende]

Klingt ja nicht so als wenn ich das nun als Neuling direkt produktiv auf 16 Rechnern nutzen möchte.

Schade die Grundidee hörte sich gut an.

[r4pt0r]

Bei 16 Rechnern ist jede manuelle Einrichtung aussichtslos - da ist man nur am Hinterherräumen wenn sich wieder was zerlegt bzw zerlegt wird....
Je nach dem was hier Unterrichtet wird wäre es ggf sinnvoller die Testsysteme direkt zentral an einem Server laufen zu lassen. Die Clients können dann wesentlich kleiner ausfallen (da keine Last von VMs) und eine einfache Standardinstallation erhalten. smartOS ist stateless und für automatisches deployment in großem stil optimiert - trotzdem würde ich keine Schulungsteilnehmer direkt an diese Systeme setzen, sondern nur zugriff auf die aktuell benötigte VM am zentralen Server gestatten.
Die VM-images können in einem zentralen repository vorgehalten werden und automatisiert (z.b. Ansible) passend zur jeweiligen Schulung oder zu Kursbeginn bereitgestellt werden. So bleibt die last am Server auf die aktuell benötigten VMs begrenzt.
Die Schulungen finden dann an den VMs am Server statt - bei linuxsystemen können auch lx-zones verwendet werden, sodass diese VMs praktisch bare-metal laufen, ohne den irrsinnigen overhead einer hardware-VM. Per snapshots lassen sich die VMs auch binnen Sekunden wieder zurücksetzen.

[Alternativende]

Sorry aber das ist für mich noch immer ziemlich nebulös, bin aber auch noch nicht sonderlich erfahren in dem Bereich.

Ich habe verstanden das du als OS smartOS empfiehlst. Das ist quasi der Unterbau ähnlich wie bei ThinClients?

Welche Virtualisierungslösung auf dem Server würdest du da empfehlen?

Wie ziehen sich die Clients denn die VM? Wo ist da der Unterschied zu einem ThinClient?

Eins der Probleme die ich habe ist ja das ich unterschiedliche Clients brauche, jeder muss seinen eigenen Namen und "Platz" in der Domäne haben, ua. wegen Exchange/Outlook etc.. Gelegentlich werden da auch Kurse bspw. zur Blildbearbeitung stattfinden, also sollte etwas Grafikperformance in jedem Fall gegeben sein. Insgesamt soll es eben schön flüssig und schnell laufen.

[r4pt0r]

smartOS ist eine illumos-basierte Virtualisierungsumgebung, die OS-virtualisierung per solaris zones und lx-zones und Hardware-virtualisierung per KVM ermöglicht. Die VMs laufen also hier, nicht auf den Clients - ausser man betreibt den Aufwand eine smartOS-Cloud (bzw Triton) aufzusetzen.
Informationen zu smartos und triton gibts hier: http://www.joyent.com

Die Clients laufen mit einem beliebigen Betriebssytem - idealerweise mit einheitlichem Setup und ein unixoides system, damit man alle wichtigen tools bereits an bord hat. Zugriff auf die VMs erfolgt dann wie gehabt per SSH oder schlimmstenfalls per VNC.

Da du aber wohl zwingend auf Windows direkt auf den Clients angewiesen bist, sind automatisierte und nicht-Hirnschädigende Lösungen wohl nicht zu realisieren; das verhindert Windows ziemlich gut... Mit chocolatey und ansible windows-tools kann man zwar einiges automatisieren, aber manuelles rumgeklicke und regelmäßige Turnschuhadministration ist die Regel bei Windows auf bare-metal...

Da ich in meinem Netz Windows für eine schrottige .NET-Anwendung zwingend bereitstellen muss, bekommen die Clients eine 08/15 Einheitstallation als virtualbox-VM (wegen USB-passthrough). Diese wird als Masterimage an einem Server als ZFS-zvol vorgehalten und einfach per zfs send/receive an die clients beim Erstsetup übertragen, automatisch konfiguriert und danach lokal gesnapshottet - schießt sich Windows wieder mal ins Knie, wird das image auf Installationszustand zurückgesetzt. Die eigentliche Arbeit und sämtliche Officeanwendungen laufen aber über das Hostsystem an den Clients (PC-BSD bzw jetzt TrueOS) - die Windows-VMs sind also reine Tretdosen in einem abgekapselten VLAN, nur mit Zugriff auf den Windowsserver, der ebenfalls nur für diese eine Anwendung laufen und mir die Nerven rauben muss... Hat auch den Vorteil, dass es im LAN deutlich ruhiger wird
Ein erstes rohes testsetup mit 4 Intel NUCs läuft seit einer Weile als Testlabor, allerdings noch mit PC-BSD CURRENT von April; sobald ich wieder Zeit dazu habe wird das ganze näher an der letztendlichen Konfiguration mit TrueOS (basiert dann auf FreeBSD 12-HEAD) gebaut, dann fallen auch einige Verrenkungen für skylake weg. Bisher ging es primär ums automatisierte deployment per ansible inklusive setup per PXE mit on-demand bootimages (ansible deploy)...

Ob sich der Aufwand in dem Schulungsraum lohnt wage ich zu bezweifeln. Wenn Windows auf bare-metal benötigt wird und nur manche Schulungen auf VMs durchgeführt werden sollen), wird dualboot und VMs auf einem zentralen Server der Sinnvollste ansatz sein. Zentral lassen sich die VMs auch einfacher haushalten; z.B. nach kursende entsorgen. Auch das deployment zu Kursbeginn ist erheblich schneller erledigt - GBit-LAN ist bei sowas ziemlich schnell _deutlich_ Unterdimensioniert...

Wenns nur um einzelne Anwendungen (Windows) geht, die bereitgestellt werden sollen, solltest du dich eher mit Windows Terminalserver vertraut machen. Die OS-Installation auf den Clients muss man eben so gut es eben geht härten, kommt aber mit Win wohl niemals um regelmäßige neuinstallationen herum.

[Alternativende]

Vielen Dank für die Erläuterungen. Ich plane mein Setup nun wohl vorerst wie folgt.

Debian als Basis, automatische Anmeldung mit XFCE als Desktop. Auf dem Desktop stehen dann zwei VM´s von VirtualBox zum starten zur Auswahl, als Icons. Klickt der Teilnehmer auf "Windows 10 Nr.1" oder "...Nr.2" wird die entsprechende VM im Vollbild gebootet. Danach erfolgt die Anmeldung an der Domäne etc., der Rest ist dann nur noch langweiliger Windowskram.

Als Basis für das Debian erstelle ich ein Image mit Clonezilla das ich dann auch vom zentralen Server aus verteilen kann. Die "tägliche" Wartung kann ich dann per WakeOnLan und CSSH auch aus der Ferne machen. Das Userprofil wird mit rsync stets zurückgesetzt, es sei denn ich erstelle ein neues Profil. Austauschen muss ich die Debianbasis so vermutlich überhaupt nicht während der Nutzungszeit der Geräte.

Als Basis für die Windowsmaschinen führe ich eine Installation in VirtualBox durch und lagere das Image auf dem Server. Diese Installation wird dann noch nicht in der Domäne sein, auch kein Sysprep, sondern einfach eine abgekoppelte Windowsmaschine die ich dann leider manuell jeweils in die Domäne einfügen muss. Anschließend erfolgt dann die Softwareinstallation etc..
Über CSSH kann ich dann Snapshots von den Maschinen anlegen, sobald sie in der Domäne sind z.B.. Aufgrund der schieren Anzahl an Maschinen 16*2 bleiben die Snapshosts dann aber lokal.

Zfs wäre schön, ist mir aber etwas zu heikel, der Aufwand mich da einzuarbeiten lohnt sich für mich derzeit nicht.

[ThorstenS]

Ich denke deine Anforderung kommt in jeder größeren Schule vor aber viele scheuen den Aufwand dahinter.
Darum mag ich auch kurz meinen Senf dazugeben.

1.)
cssh ist ganz nett. Ich benutze auch seit >12 Jahren dsh und seit ~3 Jahren die pssh, weil ich damit Dateien kopieren kann.
ABER ansible ist das, was du dir unbedingt anschauen solltest. (nimm das 2.1er backports Paket).
Damit ist soviel mehr möglich - und trotzdem sind adhoc Befehle für einzelne PCs oder eine Gruppe von PCs immer noch möglich
(ansible $HORST -a uptime )
Einstieg: http://docs.ansible.com/ansible/intro_g ... arted.html

2.)
Grub ist im Normalfall ja ziemllich häßlich! Abhilfe schafft dieses Theme, was ich unter jessie auf allen meinen Maschinen benutze: https://github.com/gustawho/grub2-theme-breeze

Aktivierung in der /etc/default/grub

Code: Alles auswählen

GRUB_BACKGROUND="/boot/grub/themes/breeze/background.png"
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_THEME="/boot/grub/themes/breeze/theme.txt"

Im icon Unterordner sind icons für jedes gängige OS dabei und die werden im Auswahlmenü auch hübsch dargestellt.
Du müßtest dir jetzt also nur eine /etc/grub.d/41_custom bauen, in der das aktuell installierte Linux aufgeführt ist mit zwei Anpassungen.
· Für jede VM brauchst du einen menuentry Eintrag und in der linux Zeile hinter quiet gibst du an vbvm=windows oder vbvm=linux (vbvm = VirtualBox VM)
· mittels --class windows kannst du dem Theme die Darstellung des Windows Icons unterjubeln. Oder --class os - schau dir das bei einem dualboot system an.

Du startest ja jetzt schon den XFCE Desktop automatisch. Also kannst du dort auch ein Script automatisch mit hochfahren, was die /proc/cmdline parst und die entspr. VM übr die .VBoxHeadless -s $NAME startet.

Falls du eine Inspiration zum Parsen von der cmdliner suchst, die Datei getbootparam bei grml ist toll.
Ich poste mal den entspr. Teil, ist ja nicht lang:

Code: Alles auswählen

stringinfile(){
    \grep -q "$1" $2 || return 1
}

getbootparam(){
    CMDLINE=$(cat /proc/cmdline)
    stringinfile "$1=" /proc/cmdline || return 1
    result="${CMDLINE##*$1=}"
    result="${result%%[   ]*}"
    echo $result
    return 0
}
getbootparam vbvm

Jetzt solltest du nur noch nach dem Übertragen der Virtualbox VMs daran denken, dass die MACs uniq sind. Auch hierfür würde ich ansible benutzen (steht in der $NAME.vbox Datei unter Network → Adapter MACAddress= ). Dann hast du nämlich sämtliche MAC Adressen der virtuellen Maschinen an einem Ort und kannst dhcp/DNS damit füttern. Das macht dir auf die lange Sicht vieles bequemer und einfacher.

Halt uns auf dem Laufenden - ich find dein Projekt spannend!
/thorsten


P.S.
Ich mag die blumige Darstellung deiner Vorlieben und Abneigungen r4pt0r

[Alternativende]

@ThorstenS
Danke für die Tipps, ist jetzt aber zu spät am Abend und zu heiß als das ich dem komplett folgen könnte .

Ich hatte da aber eben noch so eine Idee. Ich könnte bspw. mit rear automatisierte Vollbackups aller Maschinen z.B. am Wochenende anstoßen, ohne viel Aufwand. Einfach ein Skript auf dem Server das per WoL alle Clients weckt, sich per SSH einloggt, rear mkbackup anschmeißt und zum Schluß alle Clients wieder herunterfährt. So kann ich spielend leicht zusätzlich zu den Snapshosts Vollsicherungen des gesamten Raums durchführen.

[ThorstenS]

ja, vllt. hab ich es auch nicht nachvollziehbar genug aufgeschrieben. Wenn du Nachfragen hast, schick mir ruhig ne PN.

Alternativ zu ZFS kannst du auf dem Client natürlich auch BTRFS einsetzen und die Snapshots darüber auf den Server transferieren. Dieses unglaublich coole feature „send and recieve“, wo man bei ZFS snapshots platzsparend übers Netz verschicken kann, beherrscht BTRFS ebenfalls.
Ich denke da gibt es haufenweise Möglichkeiten - lediglich die zur verfügung stehende Zeit von dir setzt hier die Grenzen.

[Alternativende]

Ja mit den Möglichkeiten hast du wohl recht .
Ich denke ich bleibe bei ext4 und rear als DisasterRecovery Lösung.

Die meisten Dinge konnte ich heute schon soweit fertig machen in einer Testonstallation. Zumindest was das Debian angeht. Das automatische einloggen in XFCE funktioniert, das Profil des Users wird beim herunterfahren automatisch zurückgesetzt.

Was mir noch fehlt ist der zentrale Debianserver für die Images, Backups usw. und eine Möglichkeit das Userprofil von jedem Client zum Server zu über tragen und von da aus wieder zurück, dann an alle Clients.

Das kommt nächste Woche.

Schönes Wochenende allerseits!