Das mit der Maus hat schon ein paar Vorteile (und auch Nachteile), man klickt leichter und sieht mehr. Die XEN Konfiguration geht aber nur (noch!!) mit grafischem YAST (warum auch immer).

Also wir brauchen die Grafik sowieso. (Nachteil, man klickt schneller, leider oft, bevor das Gehirn "HALT" gesendet hat.) So sollten den X11 Client auf dem Linux Server und einen X11-Server unter WIN200/XP laufen haben. Der X11-Server tut es aber nicht korrekt, er geht, aber nur bedingt.

Unter Windows 2000 habe ich den (sehr lange gesuchten Xmin1) X11-Server probiert. Der geht aber letztendlich nicht, weil er nur ein Fenster pro Task öffnen kann. Das X11 Forwarding über Putty (nach Anleitung) war mühsam. Es hatte mehrere Stunden gedauert, weil ich es noch nie gemacht hatte und auf diverse X11-Sever-Scharlatane hereingefallen war. Mit Googeln dauerte es fast einen Tag, einen funktionierenden X11-Win-Server zu finden.

Also holt man sich per VNC die Konsole. Per Yast muss man dazu bei Netzwerkdiensten die Remote Administration frei geben und auch die Firewall erst mal abschalten. Noch sind wir im lokalen Netz. Damit ist dem VNC Client die Tür zum Server geöffnet.

Den "TightVNCViewer" Client für Windows laden Sie kostenlos von sourceforge runter und installieren den. 

Yast wird jetzt in der Konsole mit "yast --qt" aufgerufen und kommt im X-Window grafischen Modus auf. Unter VNC sind diese Systemmodule aber alle aus dem Menü links unten abrufbar.

Ganz wichtig: der TightVNC sollt mindestens Version 2.0.2 haben, die Version 1.3xx hängt des öfteren.

Yast2 funktioniert von jetzt an im grafischen X11 Modus mit Icons. Jetzt kann es endlich an die Erstellung des ersten virtuellen Gastes gehen.
.

Für die komfortable und übersichtliche Administration der einzelnen VMs auf dieser Hardware ist eine (pseudo-) grafische Oberfläche Bedingung.

Dazu benötigen wir eine X11 Obefläche und den VNC-Server auf dem Linux-Server. Den VNC-Server kann man automatisch mit Linux starten (das ist aber nicht sicher) und so werde ich ihn zur Zeit immer noch von Hand in der putty Console aufrufen.

In der Suse Firewall (wir sind immer noch beim Suse XEN DOM 0 Grundsystem) müssen die "erlaubten Dienste" für

1. SSH (hatten wir bereits bei der Netzkonfiguration erlaubt) und
2. VNC (Port 5900)

.
freigegeben sein. (Die einzelnen VMs brauchen später kein VNC, nur den Textmodus.)

Ich habe es nicht geschafft, den VNC-Server mit Konsole Nummer 1 automatsch zu starten. Er zählt bei jeden Start die Konsolen immer eine Nummer weiter hoch. Bei meinem jungfräulichen Server ist er bei ":2" angekommen. Wo der VNC-Server mit Nr. 1 geblieben ist , muss ich noch suchen.

In der Putty Consle starte ich auf dem Linux Server als root den "vncserver"
.

[root] $ vncserver

oder

[root] ~ $ vncserver -geometry 1280x1024

New 'xen-ve1496:2 (root)' desktop is xen-ve1496:2

Starting applications specified in /root/.vnc/xstartup

Log file is /root/.vnc/xen-ve1496:2.log

Es ist hier also die Console Nr.2 aktiviert worden !!!!!

In der Eingabenmaske des Windows TightVNC Viewer muß jetzt die Adresse oder IP-Nummer mit ":2" eingetippt werden und dann wird schon nach dem VNC-Server-Passwort gefragt.
.

https://www.cs.uni-potsdam.de/ti/lehre/05-ALuP-I/anleitung_vncssh.html
.

Der Autor von der oben referenzierten Seite schreibt: Ich erkläre es hier am Beispiel von PuTTY:
(Anmerkung von mir: Die Bedienung und Konfiguration von putty muss ich hier voraussetzen).

PuTTY starten
eine ähnliche wie der gewünschten Konfiguration laden

hostname oder IP Nummer eintragen
als Protokoll SSH wählen, der SSH-Server Port verbleibt bei uns bei 22

unter Connection->SSH kann man bei Protocol Options mit einem Häkchen bei Enable compression noch die Kompression für den Tunnel einschalten.

unter Connection->SSH->tunnels richtet man jetzt folgende SSH Tunnel ein:

    der lokale Port 5900 wird zur Ziel IP-Nummer auf den Port 5900 weitergeleitet.
    der lokale Port 5901 wird zur Ziel IP-Nummer auf den Port 5900 weitergeleitet.
    der lokale Port 5902 wird zur Ziel IP-Nummer auf den Port 5900 weitergeleitet.

Es bietet sich an, als Tunneleingänge ebenfalls die Ports 59XX zu nehmen, da man diese später bei der Konfiguration des VNCviewers über die Displaynummer ansprechen kann. (Port 59XX entspricht dabei Displaynummer XX).

Dazu macht man folgendes:

    bei source port gibt man 5900 ein.
    bei destination gibt man Ziel IP-Nummer:5900 ein.
    bei Local/Remote bitte auf Local klicken.
    auf "Add" klicken.

    bei source portgibt man 5901 ein.
    bei destination gibt man Ziel IP-Nummer:5900 ein.
    bei Local/Remote bitte auf Local klicken.
    auf "Add" klicken.

    bei source portgibt man 5902 ein.
    bei destination gibt man Ziel IP-Nummer:5900 ein.
    bei Local/Remote bitte auf Local klicken.
    auf "Add" klicken.

Wenn man alle gewünschten Tunnel (bei uns hier die drei Beispiele) definiert hat, sollte man diese Konfiguration / Verbindungsdaten sofort abspeichern.

Jetzt öffnet / aktiviert man den Tunnel über "Open" und holt sich damit eine Konsole auf demZiels-Server meist mit einem Hilfsbenutzer, da ja der SSH root geblockt ist. Dort holt man sich mit "su" die root rechte.

Nun startet man im putty Fenster den Windows VNC-Viewer

Anmerkung: Wir haben immer eine zweite putty Console offen, auf der wir den VNC-Server gestartet haben und kennen daher das entsprechende Ziel. In unserem Fall war es "localhost:2". Beim allerersten Male wird das von jetzt an gültige 8 stellige VNC Passwort abgefragt und gespeichert.

Jetzt kann man an jeder beliebigen Windows Station den Tight VNC Viewer aufrufen. Nur noch das VNC- Passwort eingeben und man müsste den Bildschirm des anderen Rechners sehen. Die grafische Oberfläche von yast2 geht im lokalen 100Mbit/s Netz mit dem VNC-Viewer erstaunlich schnell.

Soweit der etwas abewandelte Text aus 2004.

Wenn man nicht mit Hilfe von putty tunnelt, sondern die VNC Ports offen hätte oder sogar die VNC http Ports geöffnet hätte, wäre es sehr ratsam, den vncserver nicht automatisch zu starten, sondern von Hand zu starten und am Ende wieder zu killen.

Wird über oder durch putty hindurch getunnelt, sind also die öffentlichen VNC Ports gar nicht offen, ist nach dem Beenden von putty sowieso keine Verbindung mehr möglich.

Dieser Teil fehlt auf dieser Seite, weil es nicht funktioniert hatte.

Die Remote Konsole über ILO ist zwar immer grafikfähig, aber langsam, ILO hat nur eine Hilfs-CPU. Auch wenn diese Konsole mit Level 3 im Zeichenmodus startet, mit init=5 erlangt man sofot den X11 Modus.

Das ist bei putty anders. Für schnelle die Administration der VMs auf dieser Hardware ist wegen "yast2" eine (pseudo-) grafische Oberfläche Bedingung. Dazu benötigen wir X11 und den VNC-Server. Auf der Arbeitsstation brauchen wir einen VNC-Client (bei uns für Windows 32bit).

In der Suse 11.4 Firewall (wir sind immer noch beim Suse XEN Grundsystem) müssen die "erlaubten Dienste" für
-

1. SSH (hatten wir bereits bei der Netzkonfiguration erlaubt) und
2. VNC und
3. (nein, nicht mehr !!!) VNC-Mini-http

-
freigegeben sein (also Nicht den "VNC-Server" !!). (Die einzelnen VMs brauchen später kein VNC, nur den Textmodus.)

Ich habe es nicht geschafft, den VNC-Server Nummer 1 automatsch zu starten. Er zählt bei jeden Start immer eine Nummer weiter hoch. Bei meinem jungfräulichen Server ist er bei ":2" angekommen. Wo der VNC-Server mit Nr. 1 geblieben ist , muss ich noch suchen.

In der Putty Consle starte ich als root den VNC-Server mit "vncserver"
-

Es hatte funktioniert. Auf einem 2 GHz PC mit WIN2000 und dem alten Netscape 9 Browser mit Java 1.4 bekomme ich eine erstaunlich schnelle aber ungeschützte !!! (also nicht https verschlüsselte) grafische http R-Console mit angenehmer 1024x768 Bildgröße. Dort könnte ich jetzt im lokalen Netz meine erste VM installieren. Dieser VNC http Dienst wird aber bei uns sofort wieder abgeschaltet, weil er nicht sicher ist !!
-
Wir tunneln verschlüsselt durch putty hindurch wie folgt:

Mit dem freien Tight VNC Client (2.x) wollen wir von Windows 2000/XP auf eine X11 Linux Konsole unter Suse 11.4 XEN zugreifen. Das hat lange gedauert aber es geht jetzt. Die http Verbindung mit dem Java Browser war natürlich (zu) transparent (= unsicher), weil es kein https ist. Die wurde wieder gekillt.

Also habe ich mir per im Netz mehrer Anleitungen zusammen gesucht und eine Putty Konfiguration erstellt (und auch gleich mal gesichert), die ich als SSH Tunnel von der lokalen Windows Station zum Remote Suse 11.4 XEN Server benutze.

Wenn man es endlich weiß und es einmal gemacht hat, ärgert man sich bestimmt über die vertane Zeit. Ich entnehme jetzt ein paar Brocken von dieser uralten Seite aus 2004. fli4l.anadex.de/vnc_ssh_howto.html
Der Grundgedanke ist aber immer noch aktuell und es funktioniert recht komfortabel.

PuTTY starten (und eine ähnliche wie die gewünschte Konfiguration laden)

und uest mal den Zugang zum Server eintragen und speichern.

hostname oder IP Nummer eintragen
als Protokoll SSH wählen, der SSH-Server Port verbleibt bei uns NICHT auf Port 22, sonder wird ganz woanders hin gelegt. Das muß natüürlich auchin der sshd_config entsprechend einegetragen werden - samt restart des ssh tasks.

unter Connection->SSH kann man bei "Protocol Options" mit einem Häkchen bei "Enable compression" noch die Kompression für den Tunnel einschalten.

unter Connection->SSH->tunnels richtet man jetzt folgende SSH Tunnel ein:

der lokale Port L5900 wird mit localhost auf den Port 5900 weitergeleitet
der lokale Port L5901 wird mit localhost auf den Port 5901 weitergeleitet
und so weiter. (also nicht suf die Ziel IP Nummer, sondern auf localhost.

(Port 590X entspricht dabei vnc-server Displaynummer X).

Dazu macht man folgendes:

    bei source port gibt man 5900 ein.
    bei destination gibt man localhost5900 ein.
    bei Local/Remote bitte auf Local klicken.
    auf "Add" klicken.

    bei source portgibt man 5901 ein.
    bei destination gibt man localhost:5901 ein.
    bei Local/Remote bitte auf Local klicken.
    auf "Add" klicken.

    bei source portgibt man 5902 ein.
    bei destination gibt man localhost:5902 ein.
    bei Local/Remote bitte auf Local klicken.
    auf "Add" klicken.

Wenn man alle gewünschten Tunnel (bei uns hier die drei Beispiele vorbereitet) definiert hat, sollte man diese Konfiguration / Verbindungsdaten sofort abspeichern !!!!!!

Jetzt öffnet / aktiviert man den putty-Zugang inclusive dem putty-Tunnel über "Open" und holt sich damit eine Text-Konsole von dem Ziel-Server und bei uns erst mal mit einem Hilfsbenutzer, da ja der SSH root_login (bei uns immer) geblockt ist. Dort holt man sich mit "su" über den root User die root Rechte. Jetzt hat dieser neu VNC-Tunnel root Rechte.

Anmerkung: Wir haben immer eine zweite putty Console (ohne Tunnel-Konfiguration) offen, auf der wir den VNC-Server gestartet haben oder starten und kennen daher die entsprechende Ziel-Sub-Nummer. In unserem Fall war es "localhost:2". Beim allerersten Male wird ein 8 stelliges VNC Server Passwort abgefragt und gespeichert und ist von jetzt an gültig. Damit ist der Tunnel doppelt zugeschlossen.

Nun kann man an jeder beliebigen Windows Station (die putty config aus der Registry muß man natürlich dort über den exportierten Registry-Eintrag übernehmen/importieren) den Tight VNC Viewer (bei uns 2.0) aufrufen.
.

Wenn man NICHT mit Hilfe von putty tunnelt, sondern die VNC Ports 5900 und forlgede offen hatte oder sogar die VNC http Ports resident geöffnet hätte, wäre es sehr ratsam, den vncserver nicht automatisch über den "runlevel" zu starten, sondern immer bei Bedarf von Hand zu starten und am Ende auch wieder zu killen.

Wird über oder durch putty hindurch getunnelt, sind also die öffentlichen VNC Ports nicht mehr offen und es ist nicht zwingend erforderlich. Dann ist nach dem Beenden von putty sowieso keine Verbindung mehr möglich.
.