+++ This bug was initially created as a clone of Bug #22416 +++ Im Failover-Fall muß das alte Image kopiert werden, wenn der aktuelle Server wegen Netzwerkproblemen nicht mehr erreichbar ist. Dieser Vorgang kann längere Zeit dauern. Dem Benutzer soll dieser Vorgang im Client angezeigt werden, damit er weiß, warum es gerade nicht weiter geht. Der SB wird dazu so umgebaut, daß er nach dem 1. /connect zunächst ein /select zwischenschiebt, bevor er danach das alte /alive versendet, bis per /close die Sitzung geschlossen wird. Ursprünglich war das /connect dazu vorgesehen, auch einen Rückkanal von SB zum Client per HTTP-Long-Time-Poll zu realisieren, was aber derzeit nicht genutzt wird. Das neue /select verwendet die gleiche Technik und liefert solange weitere Statusmeldungen, bis die VM läuft (oder endgültig nicht gestartet werden kann). Entsprechender Code ist im Client bereits vorhanden (→HTTP11_streaming_client), der dann wahrscheinlich aber noch angepasst werden muß. Zunächst muß der PyQT-Client aber so erweitert werden, das er nach der Auswahl einer VM statt dem parametrisierten /alive?hostname=...&... ein /select an den SB versendet und danach dessen Antwort auswertet und dann die dort mitgelieferte Nachricht samt Fortschrittsanzeige anzeigt. Ggf. ist hier ein Cancel/Abbrechen-Button sinnvoll. Das ganze muß unter Windows (rdp) und Linux (x2go) funktionieren.
Benutzername und Passwort Felder beim QT Fenster sind jetzt bündig ausgerichtet.
/select und /alive wurden getrennt: svn24810, univention-dvs-sessionbroker_1.0.148-1
Eine erste Version ist umgesetzt. Die Übersetzungen macht Arvid: Bug #22725.
OK, ProgressBar wird beim Failover bzw. beim Start der Instanz angezeigt.
Ich habe nochmal kleine Änderungen machen müssen. Bei der DVS Anmeldung von einem Thin Client, an einem Windows 7 Client ist gelegentlich der Session Broker Client abgestürzt, wenn die Desktop Instanz neu gestartet ist. Es sieht so aus, dass mindestens ein tcp-Check nicht durch geht während der Anmeldung. Es wird jetzt abgebrochen, wenn drei Checks erfolglos waren.
Created attachment 3332 [details] uvmm, dvs sb logs und xsession-errors Hier ist noch irgendetwas durcheinander. Ich habe einen DVS Node mit laufender Session das Netzwerk weggenommen, dann am Client neu angemeldet. Das Image wurde kopiert und eine neuen Instanz auf dem noch verfügbarem DVS Node angelegt. Der Client hat aber nach einer Weile wieder den GDM Login angezeigt. Auffällig: * Internal error: need more than 1 value to unpack in xsessions-errors * anscheinend werden mehrere Session gestartet (3 connects in SB Log), angemeldet habe ich mich aber nur einmal
Ich habe nochmal mehr Debug eingebaut. Bitte nochmal reproduzieren. Für mich sieht der Ablauf wie folgt aus: - 15:47: connect als Benutzer felix, ID=5ce9be0f-98e8-11e0-a65f-5254005ce5a7 - 15:47: xen16 ist nicht erreichbar, auf dem Rechner hätte der Desktop gestartet werden sollen. Allerdings wurde um 15:13 die Instanz auf xen15 pausiert. Hast du die manuell verschoben? - 15:47: Da xen16 nicht erreichbar ist, wird der Desktop auf xen15 kopiert - 15:48: Desktop wird auf xen15 gestartet - 15:48: Erste Alive Events vom Client kommen an - 15:50: Der Client sendet ein connect, daraufhin startet der Session Broker eine neue Session, ID=d4b2865c-98e8-11e0-b8d8-5254005ce5a7 Das wiederholt sich dann und um 15:52 wird eine erneute Session mit der ID 191eace3-98e9-11e0-a01b-5254005ce5a7 gestartet. In der xession-errors ist allerdings nur diese Session-ID aufgeführt. Bist du dir sicher, dass im Hintergrund nicht noch andere Clients liefen?
Die GUI ist jetzt umgesetzt. Es wurden noch Timeouts erhöht. Teilweise gab es den Fall, dass die alte Windows Instanz mit gleicher MAC und gleicher IP auf dem ausgefallenen System erreichbar war.
ok, ich konnte keinen RDP Timeout mehr reproduzieren.