LTSP-Server virtualisieren

[bau]

Ich habe beim ltsp6 (128b/mitte) nun ein Debian 6 (Squeeze) mit einem aktuellen Proxmox aufgesetzt auf ein Raid1 (/dev/md0) über beide Platten (/dev/sda2 und /dev/sdb2) wobei ich auf jeder Platte hinten 16GB für den Swap eingerichtet habe. Der Gast (ltsp6) sollte am Besten nicht mehr swappen, ich gebe ihm vielleicht mal einfach 32GB Ram, das Swapping kann dann der Host übernehmen - oder?
Auf dem Raid1 liegt ein LVM2-VolumeGroup (pve) und darin das LVolume root für den Proxmox (gemountet als /). Ich kann diese Group dann ganz einfach dem Server als Storage einrichten, dann erstellt KVM beim Einrichten einer VM gleich ein LVolume in der Group für die VM - sehr praktisch. Das kann dann per Snapshot bequem gesichert werden.
Der Ubuntu-Install-USB-Stick wird als nächstes zur VM durchgereicht (geht auch ganz einfach) nur muss glaube ich das InstallScript angepasst werden:

• keine Swap-Partition
• kein Raid
• kein LVM (es reicht sicherlich, wenn der Proxmox-Server das LVM übernimmt, Ubuntu kann ganz einfach in eine Partition rein)
• nur eine Betriebssystempartition / keine Backuppartition
• Ich habe mal ein 50GB LVolume eingerichtet, dieses erscheint dem Gast als Festplatte (/dev/sda), die der Gast ganz normal partitionieren kann

Zu Überlegen sind:

• Setup-Script kann in Zukunft einfach ein LVM-Snapshot auf der zu kopierenden Maschine (Proxmox) erstellen und dann das komplette LVolume auf den anderen Rechner (Proxmox) kopieren, dann dort mounten (kpartx) und die Einstellungen direkt vornehmen
• Praktisch: In Zukunft muss für Veränderungen die ltsp-VM nicht mal gestartet sein, man kann einfach das LVolume mounten und Veränderungen vornehmen.
• Server-Bildschirm des ltsp kann per WebKonsole an jedem beliebigen Ort angesehen werden, allerdings ist dazu VNC2 nötig, und dazu benötigt der Browser das aktuelle OracleJava
• Auch geht das entfernte Betrachten per VNC2, welches verschlüsselt ist, derzeit kann das nur TigerVNC (Binarys unter ​http://winswitch.org/dists) - näheres unter ​http://pve.proxmox.com/wiki/Vnc_2.0
• Das Webmanagement sollte noch per .htaccess-Datei geschützt werden, nicht dass da mal jemand auf dumme Gedanken kommt

[Rüdiger Kupper]

Verschiedene Überlegungen dazu:

Frage 1: Wer swapt?

Der Gast (ltsp6) sollte am Besten nicht mehr swappen, ich gebe ihm vielleicht mal einfach 32GB Ram, das Swapping kann dann der Host übernehmen - oder?

Wie macht der das dann? Wenn Du dem Gast mehr virtuellen Speicher gibst, als der Host hat, weiß ich gar nicht, wie der damit umgeht, und wie effizient das dann ist. Hier sollten wir uns nochmal gut informieren.
So gibt es doch z.B. sicher Bestandteile des Betriebssystems (z.B. der Kernel und Passwortcache), die aus Performance- oder Sicherheitsgründen prinzipiell nicht ausgeswappt werden. Wenn der Host das Swapping macht, hat das Gastbetriebssystem darüber keine Kontrolle mehr. Ich könnte mir vorstellen, dass das zu Performanceproblemen und Sicherheitsproblemen führen könnte.

Also lieber noch mal auf einer passenden Liste nachfragen, diese Frage haben andere Leute, die mehr über Betriebssysteme wissen, sicher schon durchdiskutiert. -- Gibt es eine Proxmox-Liste?

Frage 2: Swap im RAID oder nicht?

Wie willst Du den Swap nun verwenden, auch als RAID oder als einfache Partitionen? (Siehe dazu die Stabilitätsüberlegungen in comment:3:ticket:878). Wenn wir genügend Plattenplatz haben (haben wir doch, oder?), dann würde ich die Stabilität vorziehen (also RAID). Wenn Du im laufenden Betrieb eine Platte austauschen können willst, muss ohnehin alles über RAID laufen.

Frage 3: Kein LVM im Gastsystem

kein LVM (es reicht sicherlich, wenn der Proxmox-Server das LVM übernimmt, Ubuntu kann ganz einfach in eine Partition rein)

Denke ja. Allerdings möchte ich nicht die Möglichkeit verlieren, unserem Gastsystem bei Bedarf die Rootpatition zu vergrößern oder eine zusätzliche Partition hinzuzufügen (wozu auch immer, könnte ja vorkommen).
Verstehe ich das richtig, dass man dann aber einfach ein weiteres logical volume auf dem Host einrichten kann, und dieses dann dem Gast als "normale" Festplatte erscheint? Das wäre dann ja für den Gast so, als hätte man eine weitere Platte angestöpselt. Damit hätte man die Funktionalität wieder.

[Rüdiger Kupper]

nur muss glaube ich das InstallScript angepasst werden.

Da werd ich mich mal drum kümmern, das Skript kann ohnehin noch weitere Verbesserungen vertragen.

[bau]

Swap:
OK, es ist auch überhaupt kein Problem, dem Gast ein größeres LVolume zu spendieren und ihn dann dort auch Swappen zu lassen. Zu Proxmox gibt es natürlich auch ein Forum, ...
Kannst du mal danach schauen, ich denke, das ist mehr dein Bereich.

Raid:
Ich dachte daran, das auf der Platte direkt zu machen. Ist aber auch kein Problem, das auf das Raid/LVM zu packen. Im Moment ist das beim aktuellen proxmoxltsp6 nicht mehr möglich. Kann ich dann beim nächsten machen und dann den nochmals neu aufsetzen.

LVM:
Der LVM unter dem Gast bietet volle Funktionalität - ich kann also die Platte, die der Gast benutzt auch einfach vergrößern oder ein zusätzliches Volume dazupacken, ein Snapshot des Volumes anlegen, ...
Zum Sichern wäre sowieso der Host besser geignet als der Gast.

[Rüdiger Kupper]

Replying to bau:

Swap:
OK, es ist auch überhaupt kein Problem, dem Gast ein größeres LVolume zu spendieren und ihn dann dort auch Swappen zu lassen. Zu Proxmox gibt es natürlich auch ein Forum, ...
Kannst du mal danach schauen, ich denke, das ist mehr dein Bereich.

Okay. Weiß Du zufällig aus dem Stegreif, wo ich das Forum finde?

Raid:
Ich dachte daran, das auf der Platte direkt zu machen. Ist aber auch kein Problem, das auf das Raid/LVM zu packen.

Der Unterschied ist eben: Crasht eine Platte, und der Swap lief auf dieser Platte direkt, dann crasht die komplette Maschine (Gast UND Host). Läuft der Swap über dem RAID1, kann eine Platte komplett ausfallen, ohne dass der Host oder der Gast etwas davon merken. Wenn wir uns den Plattenplatz leisten können, würde ich das vorziehen.

Im Moment ist das beim aktuellen proxmoxltsp6 nicht mehr möglich. Kann ich dann beim nächsten machen und dann den nochmals neu aufsetzen.

Kein Problem, ich sehe den Versuch mit dem ltsp6 jetzt erst mal als eine Gelegenheit, Erfahrungen zu sammeln. Der Computerraum läuft einstweilen auch ganz ordentlich mit zwei Servern. Am Freitag hab ich dort mit meinen 24 Schülern gearbeitet (Internetrecherche, Youtube), und keiner hatte irgendwelche Schwierigkeiten.

LVM:
Der LVM unter dem Gast bietet volle Funktionalität - ich kann also die Platte, die der Gast benutzt auch einfach vergrößern oder ein zusätzliches Volume dazupacken, ein Snapshot des Volumes anlegen, ...
Zum Sichern wäre sowieso der Host besser geignet als der Gast.

Gut, dann wäre das geklärt. Ich stelle das Setup-Skript so um, dass es auch direkt auf der Platte arbeiten kann.

[bau]

ProxMox-Forum: forum.proxmox.com

[bau]

Ich habe gestern mal eine VM gebootet und auf ltsp5 im Firefox die Konsole gestartet. Dort sah ich dann auch schon, dass die VM per PXE ein Linbo gebootet hatte :-)
Was haben wir denn da für eine Java-Version auf unseren ltsp? Ist das bereits OracleJava oder funktioniert das VNC2-Java-Applet jetzt auch schon mit OpenJava?
Ich würde mir jetzt auch mal TigerVNC installieren, meinst du, das können wir auch mal auf den ltsp betreiben? In den Paketquellen finde ich es nicht, man muss es aus den DEB-Packages installieren, die kann man aber in apt integrieren - ist das OK, oder zu gefährlich?

[Rüdiger Kupper]

Replying to bau:

Was haben wir denn da für eine Java-Version auf unseren ltsp? Ist das bereits OracleJava oder funktioniert das VNC2-Java-Applet jetzt auch schon mit OpenJava?

Auf den Servern ist das freie Open Java Development Kit und das darauf beruhende IcedTea-Plugin für Firefox:

linadmin@ltsp118:~$ java -version
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.3) (6b27-1.12.3-0ubuntu1~12.04)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

Es sind zwei VNC-Pakete installiert: vnc4server und das darauf aufbauende tightvnc. Mit TigerVNC hab ich keine Erfahrung, das scheint wiederum ein Fork von TightVNC zu sein.

Achtung

tightvnc funktioniert derzeit nicht stabil, siehe LtspRemoteDesktop. vnc4server klappt aber prächtig, und sehr stabil (selbst von zuhause aus über den paedml getunnelt).

[bau]

Ich meine nicht Server stellt einen Desktop per VNC zur Verfügung sondern Programm, mit dem man den VNC-Bildschrim ansehen kann. Vinaigre kann leider VNC2 (verschlüsselt) nicht.

Prima, dann genügt das Open Java DK mittlerweile, um die virtuelle Konsole des ProxMox zu starten :-)

[Rüdiger Kupper]

Replying to bau:

Ich meine nicht Server stellt einen Desktop per VNC zur Verfügung sondern Programm, mit dem man den VNC-Bildschrim ansehen kann. Vinaigre kann leider VNC2 (verschlüsselt) nicht.

Ja, klar. Ich weiß gar nicht genau, wer der eigentliche VNC-Client ist, wenn man die Verbindung im browser herstellt:

• ist der VNC-Viewer Teil von Java?
• oder Teil des Flash-Players?
• ich lese gerade, dass VNC wohl integrierter Teil von HTML 5 sein soll. Ein HTML-5-kompatibler Browser müsste demnach in Zukunft VNC-Verbindungen darstellen können ganz ohne jedes Plugin.

Jedenfalls hat irgend eines der Pakete (firefox, openjdk, vnc4server) dafür gesorgt, dass unser Firefox verschlüsseltes VNC darstellen kann.

Prima, dann genügt das Open Java DK mittlerweile, um die virtuelle Konsole des ProxMox zu starten :-)

Sieht ganz so aus, wenn Du ein Bild bekommen hast. Dann würde ich das Sun-Java auch erstmal gar nicht installieren.

[Rüdiger Kupper]

Replying to bau:

Vinaigre kann leider VNC2 (verschlüsselt) nicht.

Probier bitte mal "remmina" aus, das ist der Ubuntu-Default-Client ab 12.10.

[bau]

Laut ProxMox-VNC-Wiki (allerdings Stand August 2012) funktioniert remmina nicht (​http://pve.proxmox.com/wiki/Vnc_2.0). Auf der HP von Remmina habe ich keine Hinweise gefunden.

VNC funktioniert bei ProxMox auf verschiedene Weise:

• Klick im WebFrontend öffnet einen VNC2-Port und startet das Java-Applet auf dem Client im Browser, der dann den Port benutzt
• Man kann auch Standardmäßig einen Port einrichten oder diesen per Befehl auch adhoc einrichten und dann per VNC-Client benutzen
• Un zuletzt kann man einen VNC1-Port (nicht verschlüsselt nicht passwortgesichert!) einrichten, und diesen mit einem Standard-VNC-Client bedienen

[bau]

Ich werde morgen ltsp6 neu aufsetzen und das Software-Raid gleich richtig einrichten.

[Rüdiger Kupper]

Replying to kup:

Gut, dann wäre das geklärt. Ich stelle das Setup-Skript so um, dass es auch direkt auf der Platte arbeiten kann.

Ich setze das jetzt mal auf hohe Priorität, damit Du den virtuellen ltsp6 möglichst bald aufsetzen kannst. Sobald ich meine Korrekturen und die nötigste liegengebliebene Post erledigt habe, kümmer ich mich drum ;-).

[Rüdiger Kupper]

Okay, ich habe das Setup-Skript so angepasst, dass es erlaubt, die Partitionen ohne LVM einzurichten (mit oder ohne RAID).

Dadurch ist das Skript deutlich hässlicher geworden: Früher sahen die Devices sehr einheitlich aus, die Devices hießen immer /dev/lvmvg/{root,swap,systembackup}, egal, ob unten drunter ein RAID lag oder nicht. Das hat das weitere Skript sehr einheitlich gemacht. Jetzt brauche ich drei Fallunterscheidungen:

1. LVM (mit oder ohne RAID): /dev/lvmvg/{root,swap,systembackup}
2. kein LVM, aber RAID: /dev/md{0,1,2}
3. kein LVM, kein RAID: /dev/sda{1,2,3}

Deshalb habe ich auch schon überlegt, wie viel man verliert, wenn man in der virtuellen Maschine einfach wie bisher auch immer ein LVM einrichtet. Auch aus einem anderen Grund: oben schreibst Du:

Der LVM unter dem Gast bietet volle Funktionalität - ich kann also die Platte, die der Gast benutzt auch einfach vergrößern.

Wenn dieses Volume dann im Gast als normale Platte erscheint, ist das gar nicht so günstig: Dann würde auf einmal die virtuelle Festplatte größer werden, davon werden aber noch lange nicht die Partitionen auch größer, die darin eingerichtet sind (bei uns drei Partitionen für root, swap, systembackup).
Man muss dann also danach in der VM noch ein Partitionierungstool laufen lassen, das die Partitionen und die Filesysteme darin vergrößert. Das ist dann genauso unkomfortabel, wie auf einer realen Maschine und würde längere Zeit dauern.
Läuft in der VM dagagen auch wieder ein LVM (so wie bisher auch auf unseren echten Maschinen), kann man außerhalb der VM das LV vergrößern. Innerhalb der VM erscheint das dann wie eine größer gewordene Festplatte. Dann würde man innerhab der LVM die entsprechenden LVs vergrößern und dann die Filesysteme darin. Das würde in wenigen Sekunden gehen, sogar online.

Also Frage: Was spricht dagegen, innerhalb der VM wie bisher auch ein LVM laufen zu lassen (außer einer gewissen Unübersichtlichkeit, die der ganzen Virtualisierungsgeschichte generell innezuwohnen scheint :-) ).

[bau]

Für mich ist das kein Problem - wenn es schöner wird durch LVM machen wir halt LVM auch in der VM. Ich dachte mir nur, dass sich LVM über einem LVM doch etwas unnötig anhört.

[Rüdiger Kupper]

Replying to bau:

Für mich ist das kein Problem - wenn es schöner wird durch LVM machen wir halt LVM auch in der VM. Ich dachte mir nur, dass sich LVM über einem LVM doch etwas unnötig anhört.

Ist es auch :-). Und ich habe mal wieder einen Denkfehler begangen. (Manchmal glaube ich, Virtualisierung bringt das menschliche Vorstellungsvermögen an seine Grenzen ;-)).

Partitionierung innerhalb der VM ist gänzlich überflüssig. Man würde natürlich viel eher das folgende Setup verwenden:

• Man richtet außerhalb der VM drei LVs ein, die man als Festplatten an die VM weitergibt.
• Innerhalb der VM erscheinen diese als vollständige Festplatten (z.B. /dev/sda, /dev/sdb, /dev/sdc).
• Man richtet seine drei Filesysteme dann in diesen drei kompletten Festplatten ein, nicht in Partitionen. Man hat dann also eine "Root-Platte", eine "Swap-Platte" (die nur wenige GB groß ist) und eine "Systembackup-Platte".
• Möchte man eine dieser Platten vergrößern, so tut man das außerhalb der VM mit dem entsprechenden LV.
• Innerhalb der VM stellt sich das dann so dar, als ob die entsprechende komplette Festplatte größer geworden wäre.
• Man braucht also nur noch innerhalb der VM das entsprechende Filestem so zu vergrößern, dass es die komplette Platte ausfüllt und ist fertig.

Also muss ich mein Skript nochmal ändern, so dass es dieses Szenario abbildet. Das ist aber kein großer Aufwand.

[Rüdiger Kupper]

Die Version des Setup-Skripts ohne LVM habe ich jetzt in einer VirtualBox getestet (auf meinem Dienstnotebook, hat sich schon wieder bewährt!). Nennen wir es die aktuelle Betaversion: source:/keplertools/LTSP-setup/trunk/LTSP-setup-server@499.
Die benutzt aber noch die Partionierung, muss also nochmal angepasst werden.

[Rüdiger Kupper]

Okay, Anpassungen sind fertig, siehe changeset:500/keplertools. Das Skript unterscheidet nun zwischen:

1. virtuelle Maschine benutzte drei (virtuelle) Platten
2. physikalische Maschine
   1. mit RAID benutzt zwei (physikalische) Platten für ein RAID 1 und macht darin drei LVM-LVs.
   2. ohne RAID benutzt eine (physikalische) Platte und macht darin drei LVM-LVs.

[Rüdiger Kupper]

Das Skript verteile ich morgen auf die Setup-USB-Sticks und dann können wir einen Versuch starten, den ltsp6 aufzusetzen. Er braucht, außerhalb der VM, drei LVs, die als Platten der VM dienen:

• eine Platte für /, 50GB
• eine Platte für den Swap, 10GB
• eine Platte für /systembackup, 30GB.

Wie man die einrichtet weißt Du momentan besser als ich ;-).

[Rüdiger Kupper]

(Die Backuppartition können wir später sicher noch einsparen, da wir Backups zweckmäßigerweise außerhalb der VM machen werden. Momentan ist sie aber noch im Skript, um möglichst wenig Fallunterscheidungen zu brauchen. Langfristig strebe ich an, das Skript wieder zu vereinfachen, indem wir nur noch den virtualisierten Fall beibehalten und den "phyisikalischen Fall" entfernen. Vorausgesetzt, die Virtualisierung bewährt sich.)

[bau]

Für die Virtualisierung bietet sich ja dann ein ganz eigenes Script an, welches das LVM-Volume vom zu kopierenden Virtualisierer (A) auf den Ziel-Virtualisierer kopiert (also erst ein Sekundensnapshot auf A, dieses auf B in das dort vorhandene und dort gemountete LVM-Volume rüberkopieren und im dort gemounteten LVM-Volume die Anpassungen macht. Da der Virtualisierer B bereits läuft kann das Script auf diesem direkt ausgeführt werden.

Das bisherige Script müsste dann so angepasst werden, dass es den Virtualisierer von A nach B kopiert und dabei wie bisher RAID und LVM sowie die Einstellungen anpasst. Wobei wir einen Virtualisierer auch in 30 Minuten aus dem Stand aufsetzen können.

[Rüdiger Kupper]

Das Skript zum Aufsetzen eines geklonten LtspServers "von außen", wie unter comment:21 vorgeschlagen, ist jetzt weitgehend fertig. Ich hänge derzeit noch an einem Problem fest:

Ich habe noch nicht geschafft, "von außen" den Boot-Loader GRUB in der virtuellen Root-Platte der VM zu installieren. Es lag vermutlich daran, dass in der Platte zunächst keine Partitionstabelle eingerichtet war. Das habe ich geändert, konnte das Skript aber noch nicht testen.

Grund: Im Verlauf der Testerei mit dem Skript ist einmal etwas schiefgelaufen, und die Partitionstabelle auf /sev/sda (echte, physikalische Platte des Hosts) wurde versehentlich gelöscht. (Bug im Skript, wurde behoben.)
Ich habe daher sofort die noch intakte Partitionstabelle von /dev/sdb nach /dev/sda kopiert, wie unter AdminRaid beschrieben:

sfdisk -d /dev/sdb | sfdisk -f /dev/sda

Danach waren die Partitionstabellen wieder identisch. Der Platteninhalt dürfte ebenfalls keinen Schaden genommen haben.
sfdisk hat aber eine Meldung ausgespuckt, dass Partitionsdaten auf Systemplatten geändert wurden und ein Reboot nötig ist. Ich habe versucht, das zu umgehen, aber GRUB hat sich dann auch geweigert, einen Bootloader zu installieren.
Daher habe ich den proxmoxltsp6 rebootet, er ist aber nicht wieder hochgekommen. Vermutlich steht er am Boot-Prompt und wartet auf eine Eingabe.

[bau]

Leider bootet der ProxMoxltsp6 nicht mehr von seinen Platten, er lädt den Grub nicht und zeigt kein Bootmenu an. Das muss vor Ort vom USB-Stick wiederhergestellt werden. Ich bin grade vor Ort, weil seit gestern die Meldung von Nagios kommt, dass er nicht mehr erreichbar sei. Ich schalte ihn jetzt erstmal aus.

Ich würde den am Besten gleich ganz neu aufsetzen und den Swap auf das LVM packen.

[Rüdiger Kupper]

Okay.
Mir ist noch immer nicht recht klar, wie ich den GRUB in die virtuelle Platte installiert bekomme. Partitionstabelle reinschreiben und Partition einrichten reicht jedenfalls nicht, GRUB weigert sich, sich in das Volume zu installieren. (Vermutlich geht das auch gar nicht, weil kein echter MBR existiert.)

TODO:

• die VM mit dem Livesystem starten und probieren, ob's "von innen" auf das Device /dev/vda funktioniert. Vielleicht macht kvm da etwas, was das Device wie eine echte Platte aussehen lässt. Das hieße, dass Bootloader installieren nur "von innen" geht(?)

[Rüdiger Kupper]

Gut, wenn sich das "Aufsetzen von außen" als zu umständlich erweist, habe ich auch noch eine andere Idee, nämlich "aufsetzen von innen":

Variante 1

• *.iso-Image eines Live-Ubuntu an die richtige Stelle auf dem Host kopieren
• das Setup-Skript in ein *.iso packen. Das geht sehr einfach mit

  mkisofs -J -o LTSP-setup.iso LTSP-setup/
  

  Dieses iso ebenfalls an die richtige Stelle kopieren
• Im Proxmox-Interface beide *.iso als Storage einrichten (virtuelle CD-Roms)
• Die VM mit dem *.iso-Image de Live-Ubuntu starten (so wie bereits ausprobiert)
• Jetzt kann man "von innen" das Setup-Skript aufrufen und die Maschine aufsetzen

Variante 2

Nur das Live-Ubuntu als *.iso, davon booten, dann von innen:

• subversion nachinstallieren
• einen ssh-Schlüssel von root, kup oder bau irgendwo herkopieren
• LTSP-Setup-Skript per svn vom paedml ziehen
• Aufsetzen

[Rüdiger Kupper]

Variante 2

Aufsetzen "von außen" mit dem Skript, wie es jetzt ist, dann einmal vom live-Image booten und "von innen" noch als letzten Schritt GRUB installieren.

Das ist wohl das einfachste.

[Rüdiger Kupper]

Ich sehe, der Server läuft wieder! Klasse, vielen Dank!

[bau]

Server lief noch nicht ganz, ich musste noch die vmbr0 aufsetzen damit die VM auch läuft.
Jetzt ist es also soweit, er läuft und tut, was er soll :-)
VNC-Konsole muss halt jedesmal ein Passwort bekommen (set_password VNC <password>.

[bau]

Ich habe jetzt noch nach Anleitung auf proxmox.com einen lxde installiert, somit haben wir auch noch eine grafische Oberfläche, mit der wir weitermachen können (​http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Squeeze).

[bau]

Es dauert doch recht lange, den Server zum virtualisieren aufzusetzen. Praktisch wäre auf jeden Fall, das ein Script vom USB-Stick aus machen zu lassen.

[bau]

Ich habe mal nach einem Remote-DM geforscht und gefunden. Alle DM (xdm, gdm, kdm, lightdm) unterstützen XDMCP, ein Netzwerk-UDP-basiertes Protokoll, mit dem man sich an einer anderen Maschine am entfernten Server einloggen kann. Ich habe das mal auf ltsp5 eingerichtet in der /etc/lightdm/lightdm.conf einfügen:

[XDMCPServer]
enabled=true  

und anschließend den lightdm neu starten. Auf ltsp7 habe ich das remmina-plugin-xdmcp installiert, um das Teil zu testen - ich erhalte damit den Login-Screen des ltsp5 auf den ltsp7 - schön.

Installierst du das bitte auf allen ltsp (habe grade dafür keine Zeit mehr)- DANKE!

Der proxmoxltsp6 hat ja seit gestern ein X mit gdm2, der bietet unter Aktionen den XDMCP-Chooser, leider ist es mir bislang nicht geglückt, auf den ltsp5 zuzugreifen. Das wäre dann aber die Lösung: Man würde dem User auf dem proxmoxltspX einen gdm so einrichten, dass der sich automatisch am ltspX einlogged.

[bau]

Test hat nun ergeben, was auch unter ​https://wiki.ubuntu.com/xdmcp nachlesbar ist: XDMCP ist unverschlüsselt und langsam (weil unkomprimiert). Alternative wäre NX (​https://help.ubuntu.com/community/FreeNX), oder vielleicht das, was die LTSP-Clients so machen.

[Rüdiger Kupper]

Oder RDP. Die neueren Ubuntu-Versionen haben direkt auf der Login-Screen die Option, sich per RDP remote auf einer anderen Maschine einzuloggen.

[Rüdiger Kupper]

Der virtuelle ltsp6 hat nur einen virtuellen Prozessor, ist das so gewollt?

[Rüdiger Kupper]

Ich hab mal auf 8 Cores hochgestellt.

[Rüdiger Kupper]

Hm, also das Ausetzen von außen wirkt nicht sonderlich elegant. Irgendwie hat man ständig das Gefühl, etwas zu machen, was eigentlich nicht vorgesehen ist.

Besonders abenteuerlich ist der Schritt, wo ich in das LVM-Volume, das später die Root-Platte werden soll, eine Partitionstabelle schreibe und eine Partition anlege. Die muss man dann erstmal im /dev/-Dateisystem finden! Bei uns liegt sie offenbar unter /dev/mapper/pve-lvm--100--disk--1p1. (Das Anhängsel p1 verweist offenbar auf die 1. Partition). Ob dieser "mapper"-Devicepfad aber portabel ist, oder ob der sich von mapper-Version zu mapper-Version ändert, weiß kein Mensch.

Ich denke, die eigentlich vorgesehene Methode ist, ein *.iso einzubinden und die VM damit zu booten. Dann befindet man sich in einem geschlossenen System, alle Platten erscheinen als echte Devices (/dev/vda, /dev/vda1, etc), der GRUB lässt sich installieren, etc.

Also ich probiere jetzt mal, ob ich die Maschine "von außen" aufgesetzt bekomme, aber sauberer fühlt sich das Ausetzen von innen an...

[Rüdiger Kupper]

Okay, neue Erkenntnis: Der GRUB lässt sich doch von außen installieren, wenn sich in der Partition ein funktionsfähiges Linux befindet.

TODO

Allerdings muss man ihm beibringen, in die GRUB-Konfig nicht den Namen des Devices zu schreiben, wie es für grub-install aussieht (/dev/mapper/pve-lvm--100--disk--1p1), sondern /dev/vda1. Das geht irgendwie über die Device-Map (googeln!)

-> Querverweis: #993

Bin aber noch immer nicht überzeugt, ob Aufsetzen von innen nicht sauberer ist.

[Rüdiger Kupper]

Erfolg: Jedenfalls läuft der virtuelle ltsp6 jetzt! Du kannst ihn über VNC sehen, Passwort ist gesetzt.

Hinweis: Ich musste die virtuelle Grafikkarte von "Default" auf "Standard VGA" stellen, sonst hatte die Grafik immer Fehler. (Was ist denn "Default" für eine Grafikkarte? Da stimmte offenbar der Treiber nicht.)

Die Maschine ist eine Kopie des ltsp5. Der Server müsste eigentlich auch bereits wieder seine LTSPServer-Tätigkeit erledigen, ich habe ihn daher in der dhcpd.conf.kepler wieder einkommentiert.
Wenn Du da bist, probier doch mal aus, ob die Clients booten!

Ich melde mich jetzt ab in den Urlaub :-), bin ab morgen Nachmittag bis zum Ende der Ferien weg.

[bau]

Clients booten vom virtuellen Server - ich merke erstmal keinen Unterschied :-) es scheint alles zu funktionieren!

Der mdadm mäkelt natürlich jeden Tag mal rum, da je kein Raid mehr da ist, auch der apcupsd ist natürlich obsolet, der werkelt ja auf dem proxmoxltsp.

Jetzt wäre noch der BenchmarkTest interessant.

[Rüdiger Kupper]

Replying to bau:

Der mdadm mäkelt natürlich jeden Tag mal rum, da je kein Raid mehr da ist, auch der apcupsd ist natürlich obsolet, der werkelt ja auf dem proxmoxltsp.

Jetzt wäre noch der BenchmarkTest interessant.

Okay, kümmere mich darum.

[Rüdiger Kupper]

Der Benchmarktest läuft gerade auf allen sieben Servern.

[Rüdiger Kupper]

Mir ist derzeit nicht klar, wie ich ein Backup des virtuellen Servers anlege.

Bei den "echten" Servern erzeuge ich einen LVM-Snapshot der Rootpartition, den ich dann in Ruhe per rsync ins dafür vorgesehene systembackup-LVM-Volume kopiere.

Im virtuellen ltsp6 gibt es kein LVM mehr. Von außen auf dem Host sehe ich zwar das LVM-Volume "pve/vm-100-disk-1". Davon kann ich auch erfolgreich einen LVM-Snapshot anlegen. Mit diesem Snapshot kann ich dann aber nicht weiterarbeiten, es handelt sich ja um ein komplettes Festplattenimage mit Partitionstabelle und einer eingerichteten Partition. Leider sehe ich keine Möglichkeit, diese Partition des Snapshots irgendwohin zu mounten. Unter /dev/mapper/ taucht sie jedenfalls nicht auf.
Daher kann ich auch keine Kopie per rsync davon anlegen.

Der andere Weg, über das Webinterface von proxmoxltsp6, schlägt derzeit fehl, weil es keinen "Storage" für den Backup zu geben scheint. -- Weißt Du, wie das geht?

Ich bin noch nicht recht zufrieden, weil ich den Eindruck habe, nicht genügend Kontrolle über die Plattenstruktur des virtuellen Servers zu haben. Diese Partitionstabelle innerhalb des LVM-Volumes ist irgendwie sehr unhandlich...

[bau]

Das hat Holger Baumhof gut beschrieben unter ​http://www.linuxmuster.net/anwenderwiki:virtualisierung:kvm:kvm_ubuntu1204?s[]=libvirt#backup_mittels_lvm_snapshot_und_einem_qnap_nas Du brauchst noch kpartx, damit kannst du das LVM-Snapshot mit seiner internen Partitionstabelle an eine bestimmte Stelle mounten.

[Rüdiger Kupper]

Der Benchmark ist durch: ​Ergebnis.
Hier zum besseren Vergleich die ​normalisierten Ergebnisse (größere Zahl ist besser).

Der virtualisierte Server schneidet schon bei vielen Tests schlechter ab. Fragt sich, welchen Schluss wir nun daraus ziehen...

[Rüdiger Kupper]

Ich schließe dieses Ticket ab, da der virtualisierte Server verlässlich läuft.
Für die Virtualisierung der übrigen Server (sofern wir uns dafür entscheiden) eigenes Ticket eröffnen.

[bau]

Die virtualisierten Server laufen nicht mit einem RAID. Der mdadm läuft aber immernoch als Daemon und verschickt einmal täglich eMails, dass das Raid nicht funktionsfähig ist. Ich habe nun in der /etc/default/mdadm den Serverstart verhindert und den mdadm gestoppt, die Meldung sollte nun nicht mehr auftauchen!

[Rüdiger Kupper]

Das mdadm-Paket kann auf diesen Servern auch einfach ganz entfernt werden.

[bau]

Ich habe gerade den ltsp8 (virtuell von proxmoxltsp6, gesichert als tgz unter /systembackup) per sftp auf den proxmoxltsp4 (Ich musste erstmal ein neues Storage pvebackup auf dem Raid einrichten, welches der Debian-Proxmox freundlicherweise gleich auch erkannt hatte) und dieses nach /sysbackup mounten, da das sysbackup in der lvmvg zu klein für das tgz war :-) Dann ist es aber recht leicht:

• Im WebInterface das Storage / Backup bekanntmachen
• dort das Backup anklicken und [Restore]
• nach einigen Minuten ist die VM bereits verfügbar
• alten ltsp8 ausschalten
• In der Config-Datei (unter /etc/pve/qemu-server) muss die IP angepasst werden, im Webinterface muss noch die zweite VirtIO-Platte (wird nicht mitgesichert, ist ja SWAP) angelegt werden

und schon läuft der ltsp8 nicht mehr auf proxmoxltsp6 sondern auf proxmoxltsp4 ;-)

[Rüdiger Kupper]

Könnte mir vorstellen, dass die "Migration"-Methode das von selbst macht.


Schön!
Wie heißt der Host? proxmoxltsp4?
Hat der ein ext4-Dateisystem mit den Einstellungen für eine SSD?

Rüdiger

[Rüdiger Kupper]

Ich nehme grade mal die Einstellungen für die SSD vor (siehe AdminSsd).

Was ich nicht verstehe: proxmoxltsp6 hat zwei Swap-Volumes:

root@proxmoxltsp4:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/pve-pve--root /               ext4    errors=remount-ro,discard 0       1
/dev/mapper/lvmvg-swap none            swap    sw,discard              0       0
/dev/mapper/pve-pve--swap none            swap    sw,discard              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Wie ist das gemeint?

[Rüdiger Kupper]

Hier ist noch eine Sache, die nach der Migration angepasst werden muss: ltsp8 findet derzeit seine Swap-Partition nicht:

root@ltsp8:~# swapon -s
Filename				Type		Size	Used	Priority
root@ltsp8:~# swapon -a
swapon: cannot find the device for UUID=620c2393-5074-4ef9-b1b3-909c3b811892

[Rüdiger Kupper]

Täusche ich mich, oder ist auf /dev/vdb noch gar kein Swap eingerichtet?

[Rüdiger Kupper]

So, jetzt gibt es Swap auf /dev/vdb1. (32 GB -- ist das richtig?)

[Rüdiger Kupper]

Okay, habe ihm noch den gesamten Speicher gegeben (15GB von Anfang an, nicht dynamisch, weil er sich ja nun den Host nicht mehr teilt), und VNC läuft jetzt auf dem Default-Port 5900.

[Rüdiger Kupper]

Habe den "alten" ltsp8 auf proxmoxltsp6 auf "start at boot=no" gesetzt, damit wir nicht versehentlich zwei davon laufen haben.

[bau]

• Ich habe bei proxmoxltsp4 wie gewünscht ext4 benutzt (wir haben ja auch keine openvz-VM drauf.)
• das proxmox-Debian erkennt bereits bei der Installation das bestehende LV und bindet den SWAP von dort automatisch ein, deshalb hat der zwei SWAP-Bereiche, eigentlich reicht ja der auf der SSD
• die zweite HDD wird ja naicht mitgesichert und ich musste diese neu anlegen. Follich bekommt die wohl eine neue UUID und muss vor allem erstmal als SWP eingerichtet werden, die "PLatte" ist ja vollkommen unpartitioniert
• die zweite Platte hatte ich mit 16GB eingerichtet, warum zeit der nun 32GB an?

Wir müssen diese Schritte irgendwo dokumentieren!

[Rüdiger Kupper]

Replying to bau:

• die zweite Platte hatte ich mit 16GB eingerichtet, warum zeit der nun 32GB an?

root@ltsp8:~# parted /dev/vdb print
Modell: Virtio-Blockgerät (virtblk)
Festplatte /dev/vdb: 34,4GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos

Nummer Anfang Ende Größe Typ Dateisystem Flags

1 1049kB 34,4GB 34,4GB primary linux-swap(v1)

Tja, die ist definitiv 32GB groß. Vielleicht hast Du Dich einfach vertippt. Sollen wir das noch ändern (schadet ja erstmal nicht. Außer, dass dann 16GB mehr für Systembackups Platz wären. Aber die sollten eh nicht auf die SSD)

Wir müssen diese Schritte irgendwo dokumentieren!

Richtig. Auch das Aufsetzen eines Proxmox (da gibt es schon Wikiseiten, die müssen vielleicht mal aktualisiert werden.)

[Rüdiger Kupper]

Habe auf proxmoxltsp4 nun auch die XDMCP-Verbindung zur VM eingerichtet. (Im Wiki dokumentiert unter AdminProxMox).

Kollegen können nun wieder direkt am Server in Stützpunkt 4 arbeiten, als säßen sie an der virtuellen Maschine.

[Rüdiger Kupper]

Ich glaube, dieses Ticket ist erledigt, oder?

[Rüdiger Kupper]

Die restlichen Server sollen ebenfalls virtualisiert werden.

[Rüdiger Kupper]

@bau: Bitte SSDs einbauen.

[Rüdiger Kupper]

Alle Schülerserver sind jetzt virtualisiert und laufen mit der Trusty-Installation (ebenso ltspl2).

Todo

• proxmoxltsp7 ist defekt, Speicher muss getauscht werden, danach die VM noch umbenannt und mit Swap ausgestattet werden
• ltspl1 muss noch virtualisiert werden.

[Rüdiger Kupper]

Todo

- auf proxmoxltsp7 die /etc/apt/sources anpassen und Proxmox auf 3.2 updaten

[jas]

ist das denn noch aktuell? Wir steigen ja auf ein anderes System um,... somit hätte sich das hier ja eigentlich erledigt... oder?

[bau]

Die LTSP-Server sind alle virtualisiert - wir werden nach dem Umstieg auf die neue Hardware noch einige erhalten, die meisten davon sind dann aber überflüssig und stehen als weitere Clients (sehr leistungsfähig) zur Verfügung.