Rößner-Network-SolutionsDurch die Umstellung auf VDE ergaben sich neue Herausforderungen. Die Versionen von libvirt unterstützen zum Releasezeitpunkt von Ubuntu Hardy und Intrepid leider noch kein VDE. Daher hatte ich in einem vergangenen Artikel kurz beschrieben, wie man KVM-Instanzen auch manuell starten kann.
Nutzt man hingegen KVM in einer produktiven Umgebung, so benötigt man recht bald ein Init-Skript, dass zum einen die Instanzen in geordneter Reihenfolge starten und stoppen kann, zum anderen eine Möglichkeit, ACPI-events wie z.B. Powerbutton-pressed zu senden. Das folgende Skript und eine Beispielverzeichnisstruktur zeigen, wie man das mit der Bash lösen kann.
Das Skript orientiert sich an einem gewöhnlichen sysvinit-Konzept. Ich habe mich entschieden, Start- / Stoppskripten innerhalb von /etc/kvm zu platzieren. Dort muss zu erst ein Ordner instances erstellt werden. In diesem dann ein Ordner rc
mkdir -p /etc/kvm/instances/rc
Innerhalb von /etc/kvm/instances werden alle Gast-Skripten abgelegt. Diese müssen in der Form gastname (beliebiger Name ohne Extension) vorliegen.
Im nächsten Schritt werden innerhalb des rc-Ordners die Gäste verlinkt. Hier ein Beispiel meines Test-Servers:
lrwxrwxrwx 1 root root 9 2008-12-09 09:01 K87www -> ../www
lrwxrwxrwx 1 root root 8 2008-12-09 09:01 K88mx -> ../mx
lrwxrwxrwx 1 root root 9 2008-12-09 09:00 K89dns -> ../dns
lrwxrwxrwx 1 root root 8 2008-12-09 09:00 K90db -> ../db
lrwxrwxrwx 1 root root 8 2008-12-09 09:00 S00db -> ../db
lrwxrwxrwx 1 root root 9 2008-12-09 09:00 S01dns -> ../dns
lrwxrwxrwx 1 root root 8 2008-12-09 09:00 S02mx -> ../mx
lrwxrwxrwx 1 root root 9 2008-12-09 09:01 S03www -> ../www
Wie man sieht, gibt es S und K Skripten. S steht hierbei für Start und K für Stopp (Kill).
Diese symbolischen Links regeln die Reihenfolge, in der Gäste später gestartet und beendet werden. Dies ist bei mir recht wichtig, da ich nicht alle Gäste synchron hochfahren möchte. Grund ist, dass die Datenbank und der Nameserver essentielle Voraussetzungen für weitere Gäste darstellen.
Ein Gastskript hat nun in etwa folgende Struktur:
#!/bin/sh
vdekvm -m 256 -smp 2 \
-name www \
-boot c \
-drive file=/dev/mapper/vg01-kvm3--disk,if=virtio,boot=on \
-net nic,vlan=0,macaddr=00:16:3e:bf:e6:be,model=virtio \
-net nic,vlan=1,macaddr=00:16:3e:bf:e6:bd,model=virtio \
-net vde,vlan=0,sock=/var/run/vde2/vde0.ctl \
-net vde,vlan=1,sock=/var/run/vde2/vde1.ctl \
-k de \
-vnc 127.0.0.1:2 \
-monitor tcp:127.0.0.1:2023,server,nowait \
-serial none \
-parallel none \
-localtime \
-daemonize > /dev/null 2>&1
# vim: ts=2 sw=2 expandtab
Update 2010-09-14: Bitte weitere Artikel anschauen; es gibt immer mal Änderungen hier 😉
In der aktuellen Version kann kvm oder der Wrapper vdekvm genutzt werden. Das Skript erkennt dies automatisch.
Wichtige Punkte sind hier der Gastname und die -monitor Option. -serial, -parallel und -localtime sind optional.
Das folgende Skript ist nun das abschließende init-Skript, welches den Start aller oder einzelner Gäste und Beendigung vice versa durchführt.
WICHTIG: Das Skript kann im Regelfall nur als Benutzer „root“ ausgeführt werden! Bei Ubuntu also einfach mal ein sudo -i absetzen und weiter geht´s.
Achtung! Ich entwickle das Skript immer noch weiter. Also einfach mal von Zeit zu Zeit hier schauen, ob es eine neue Version gibt.
Hier der Download-Link des Skripts
Da auch Urs inzwischen viel an diesem Script gearbeitet hat, stelle ich hier seine Version zum Download bereit: KVM.zip
Auf die genauen Details möchte ich nicht hinweisen. Grob gesagt arbeitet das Skript über die PIDs der einzelnen Gäste und kümmert sich ebenfalls um verwaiste vdekvm-Wrapper-Skripten.
Wer interesse hat oder Fragen, kann hier ja wie immer gerne Kommentieren. Ich freue mich über jede Anregung.
Kleines Beispiel mit telnet zur Verwaltung einer VM:
Beispiel:
$ # ./kvm-manage monitor db
use telnet to monitor VM db at: 127.0.0.1:2023
$ # telnet 127.0.0.1 2023
Dann „help“ tippen, um eine Liste der Kommandos von qemu zu erhalten
Man kann das Script übrigens auch nach /etc/init.d vershieben. Bindet man es beispielsweise unter Ubuntu wie folgt ein
update-rc.d kvm-manage defaults 90 00
so werden die Gäste auch beim Starten/Herunterfahren sauber prozessiert.
[ Update 2011-04-07 ]:
Nachdem nun zwei Mal berichtet wurde, dass es Fehler im Skript gäbe, wurde ich dann doch hellhörig. Ich habe daher noch mal nachgeschaut woran es liegt, dass es „socat“-Fehler gibt. Die Antwort ist trivial:
ich habe bei mir den Betrieb von TCP auf Unix-Sockets umgestellt. Eine Gastmaschine wird bei mir derzeit in etwa wie folgt gestartet:
/usr/bin/screen -dmS kvm-mx0 -- /usr/bin/kvm \
-uuid f1549c00-dcb8-4a4d-8b89-43083507aaf1 \
-m 2048M \
-cpu host \
-smp 2,cores=2 \
-balloon virtio \
-name mx0 \
-drive file=/data/kvm/mx0.qcow2,if=virtio,boot=on,cache=writeback \
-net nic,vlan=0,macaddr=54:52:00:bf:e6:ba,model=virtio \
-net tap,vlan=0,script=/etc/kvm/scripts/vlan0-ifup,downscript=/etc/kvm/scripts/vlan0-ifdown \
-net nic,vlan=1,macaddr=54:52:00:bf:e6:b9,model=virtio \
-net tap,vlan=1,script=/etc/kvm/scripts/vlan1-ifup,downscript=/etc/kvm/scripts/vlan1-ifdown \
-net nic,vlan=2,macaddr=54:52:00:6e:e7:14,model=virtio \
-net tap,vlan=2,ifname=vnic0,script=/etc/kvm/scripts/vlan2-ifup,downscript=/etc/kvm/scripts/vlan2-ifdown \
-watchdog i6300esb \
-nographic \
-vga none \
-serial stdio \
-monitor unix:/var/run/kvm/mx0.sock,server,nowait \
-chroot /chroot \
-runas mx0
sleep 3
/usr/bin/renice -n -15 -u mx0 > /dev/null 2>&1
/usr/bin/ionice -c 1 -n 2 -p $(ps -o pid=,args= -C kvm | grep -- "-uuid f1549c00-dcb8-4a4d-8b89-43083507aaf1" | awk '{ print $1; }')
# vim: ts=2 sw=2 expandtab
Hier zeige ich auch zugleich, wie man eine virtuelle Maschine noch gut in der Performance anheben kann.
Viel spaß und Danke für Anregungen.
Das ist eigentlich genau das was ich suche. Ich werde das Script unter Debian verwenden und hätte hier noch eine kleine Anregung.
Wäre nicht schlecht, wenn in deinem Script noch die Download-URL und Deine E-Mail Adresse stehen würde.
Dies würde mir helfen, bei späteren Updates des Scripts…
Danke für die Anregung. Ich habs direkt eingetragen.
Noch ein kleine Anregung.
Das Skript ist starr auf vdekvm eingestellt (list). Es funktiniert aber ausgezeichnet mit kvm. Nur sollte das Skript dann entsprechend angepasst werden. Hier wäre es vorteilhaft, wenn „kvm“ oder „vdekvm“ als variable im Kopf definiert ist oder sonst irgendwo.
Das ist richtig. Ich verwende derzeit vdekvm, weil ich bei mir VDE nutze. Ich bin aber auch gerade dabei herauszufinden, wie vdeq das ganze mit TAP für kvm wrappt. Ich will das nämlich im Endeffekt gerne manuell laufen lassen, damit ich dann auch vde_switch-Konfigurationen mit übergeben kann. Dann klappt nämlich später auch so etwas wie VLANs auf dem Switch, was sehr genial wäre.
Da gibt es nur 2 Probleme: a) vdecmd ist broken.
b) Ich kann keine Ports im vde_switch vorher in VLANs aufteilen, weil er da noch keinen Link zu Gästen hat.
Das Skript wird sicher noch angepasst. Ich muss nur mal durchdenken, ob es auch mit kvm direkt gehen würde, oder ob mir dann die PID-Behandlung um die Ohren fliegt.
Stay tuned.
P.S.: Mache gerade simmultan noch zwei andere Dinge. Keine Ahnung, ob man meine Antwort jetzt verstehen kann.
Hab einige änderungen vorgenommen.
Minicom erscheint mir nicht ganz das Wahre zu sein, um das Monitoring zu starten.
Ich habe nun das ganze nun mit tcp auf einen Port gemappt. Somit lässt sich via
telnet oder einem anderen tcp-fähigem Terminal zugreifen…
Grund:
Wenn ich den -daemonize parameter verwendet habe, hatte ich keinen monitor
mehr. Das pty device wurde nicht angelegt oder war falsch… hat aber was mit kvm
zu tun und nicht mit deinem Script.
Hier nun die änderungen:
TELNET_CMD=“/usr/bin/telnet“
<>
get_pidline() {
ps -o pid=,args= -C kvm | grep — „-name $1“
}
<>
<>
do_stop () {
echo „Stopping VM: $1“
pidline=$(get_pidline $1)
if test -n „$pidline“; then
var1=${pidline#*-monitor*}
ip=`echo $var1 | cut -d “ “ -f 1 |cut -d, -f1 |cut -d: -f2`
port=`echo $var1 | cut -d “ “ -f 1 |cut -d, -f1 |cut -d: -f3`
$LOG_CMD $LOG_OPTS „Shutting down VM($1) on monitor $ip:$port“
echo „system_powerdown“ | $TELNET_CMD $ip $port > /dev/null 2>&1
# Waiting for the guest to terminate
for timer in $(seq 1 20); do
pid=$(get_kvm_pid $1)
if test -z „$pid“; then
$LOG_CMD $LOG_OPTS -s „VM($1) shutdown complete“
break
fi
sleep 5
done
# Error! We kill the guest
if [ $timer -eq 20 ]; then
# Try to save a screendump
echo „screendump /tmp/kvm-$pid.ppm“ | $TELNET_CMD $ip $port
sleep 3
kill -TERM $pid > /dev/null 2>&1
$LOG_CMD $LOG_OPTS -s „VM($1) killed!“
fi
fi
}
<>
<>
test -x $TELNET_CMD || error „$TELNET_CMD required!“
<>
<>
monitor)
if test -z „$2“; then
error „$0 monitor “
else
name=$(basename $2)
pidline=$(get_pidline $2)
if test -n „$pidline“; then
var1=${pidline#*-monitor*}
ip=`echo $var1 | cut -d “ “ -f 1 |cut -d, -f1 |cut -d: -f2`
port=`echo $var1 | cut -d “ “ -f 1 |cut -d, -f1 |cut -d: -f3`
echo „use telnet to monitor VM $name at: $ip:$port“
fi
fi
;;
<>
Desweiteren habe ich noch einen Fehler gefunden in der start) Sektion (einzelne vm’s starten).
original: if test -x /etc/kvm/instances/$name; then
modifiziert: if test -r /etc/kvm/instances/$name; then
Die Instanzen müssen nicht ausführbar sein….
Gruss
Urs
Hab noch was vergessen. In den Instanzen heisst’s natürlich nicht mehr
-monitor pty
sondern
-monitor tcp:192.168.20.6:2002,server,nowait \
Vielen Dank, ich finde diese Variante auch besser und habe die Änderungen eingebaut.
Du hast den folgenden Teil noch vergessen zu übernehmen. Es existiert kein $pty mehr
<>
# Error! We kill the guest
if [ $timer -eq 20 ]; then
# Try to save a screendump
echo “screendump /tmp/kvm-$pid.ppm” | $TELNET_CMD $ip $port
sleep 3
kill -TERM $pid > /dev/null 2>&1
$LOG_CMD $LOG_OPTS -s “VM($1) killed!”
fi
fi
<>
Ups, danke. Hab´s noch ergänzt. Hoffe, es ist jetzt fehlerfrei(er) 🙂
croessner, beschäftigst Du Dich noch mit dieser Materie? Der letzte Eintrag zu KVM/VDE ist ja schon ein Weilchen her, und auch Dein Skript endet mit dem Datum 24.01.2009.
Wie es scheint, wird VDE weiterhin nicht von libvirt unterstützt, was natürlich schade ist, da man somit immer noch auf alle Management-Tools verzichten muß, die auf libvirt aufbauen.
Es ist verdammt schwierig, aktuelle Info zu dieser Thematik zu finden, und ich bin gerade dabei, die einzelnen Puzzle-Teile zusammenzufügen. In meinem geplanten Setup möchte ich auf VDE nicht verzichten, da es einfach der richtige Ansatz ist. libvirt mit NAT oder Bridge Setup hat mit heute bei meiner Testinstallation jede Menge Kopfschmerzen verursacht, da mir das überhaupt nicht zusagt, wenn libvirt mir mein iptables-Setup durcheinanderbringt.
Hi, ja ich beschäftige mich immer noch mit dem Thema und ich nutze auch noch immer dieses Skript hier. Urs hat mir freundlicherweise noch eine Aktualisierung zugeschickt, aber weil ich derzeit an meiner Abschlussarbeit sitze, finde ich einfach keine Zeit, mir die Neuerungen mal in Ruhe abzuschauen. Aber das mache ich noch garantiert, versprochen!
Das Skript hier funktioniert bei mir aber auch schon so ganz gut
Könntest Du diese aktualisierte Version von Urs online stellen? Würde mir das auch gerne sogleich ansehen.
Soeben ins Netz gestellt
Well, die Version von Urs sieht gut aus, der Ansatz mit den echten Config-Files ist schon mal der richtige Weg. Was es mit dem Nagios-Support auf sich hat, verstehe ich nicht, da der Teil betreffend Nagios im Skript scheinbar nichts tut (allerdings habe ich bislang keinerlei Erfahrung mit Nagios, da noch nie eingesetzt).
Ich stehe jetzt gerade bei der Überlegung an, wie man am besten den Zugriff per vncviewer über SSH regelt. Vielleicht könntest Du dazu ja eine Kleinigkeit schreiben, wie Du auf Deinen Rootserver zugreifst, wenn Du mal in eine der VMs per VNC rein willst.
Ich sehe das anders. Ich wollte ein Init-Skript. Mir fehlt dann die klare Trennung von Init-Skript und Applikation. Aber das ist Geschmackssache. Ich wollte von Anfang an nur ein Init-Skript, welches mir die KVM-Gäste in sauberer Reihenfolge starten und stoppen kann. Möglichst keinen Eingriff in den puren KVM-Aufruf eines jeden Gastes. Aber wie schon gesagt: Jedem so, wie er sich wohl fühlt, deshalb habe ich die Version ja jetzt auch so wie sie ist mit hier aufgenommen.
VNC spreche ich direkt über ssh -X … an. Das ist recht unpoblematisch, weil selbst ein Disconnect ja nicht die offene Session schließt. Setzt natürlich entsprechende Breitbandverbindung voraus (was ich mit 20MBit down, 1MBit up hier habe).
Nagios selbst ist interessant im Zusammenhang mit SNMP und kann halt gut konfiguriert werden, um jeden einzelnen Gast zu monitoren. Gerade in Zusammenhang mit Distributed-Nagios ist das sehr schön. Ich habe leider keine fertigen Configs hier, um das mal eben zu zeigen. Ich glaube, man kann auch irgendwie mrtg und rrdtool in Nagios integrieren. Aber das sind alles nur erstmal Ideen. Grundsätzlich habe ich bereits erfolgreich einen Nagios-Server mit dazugehörigem Distributed-Nagios aufgesetzt und getestet.
Ich werde dazu sicher in schon recht naher Zukunft mal einen Artikel dazu schreiben.
Also die Version von Urs ist ja weiterhin ein Init-Skript, der Unterschied ist, daß die Prozedur des Aufrufs vom Gastskript in das Init-Skript verlagert wurde, und somit das Gastskript nur noch die Parameter beinhaltet. Funktionell kommt es ja auf dasselbe raus.
Betreffend VNC: Du hast den vncviewer also auf dem Host installiert, und nicht auf der Workstation, von der Du auf den Host zugreifst, habe ich das jetzt richtig verstanden? Irgendwie hatte ich die ganze Zeit die Idee im Hinterkopf, einen SSH-Tunnel aufzubauen, und mit einem vncviewer, der auf der Workstation installiert ist, über den Tunnel auf die VMs am Rootserver zuzugreifen.
Mit Nagios / SNMP / mrtg / rrdtool habe ich überhaupt noch keine Erfahrung, bin also schon sehr gespannt, wenn Du dazu was schreiben wirst. 😉
Ich sag mal so: ich habe bei mir einen OpenVPN-Tunnel zum Gastgeber und kann dann sehr bequem vom heimischen VNC-Viewer die Gäste anzeigen lassen 🙂
Ich habe ein Forum eingerichtet. forums.roessner-net.com. Las uns diskussionsbeiträge besser dort platzieren 🙂
Danke
Bitte schlag mich jetzt nicht 🙂 Ich habe das Forum doch erstmal für unsere Singles reserviert. Schreiben wir doch eher hier weiter. Das verschreckt sonst die Frauen 🙂
Damned, zu spät gelesen 🙂
Ich stehe mit dem Fehler jetzt erstmal an, wenn sich da auf die schnelle keine Lösung findet, werde ich wohl oder übel doch wieder auf ein libvirt-supportetes Bridged-Setup umsteigen müssen, da hierfür dann der Aufwand einfach zu groß wird.
Solange libvirt VDE nicht unterstützt, kann man sich damit so ziemlich den Schuh aufblasen, es gibt praktisch keine aktuelle Info bzw. Support, da nun mal jeder andere, der KVM/KQEMU (insb. auch unter Debian & Ubuntu) einsetzt, ganz einfach die auf libvirt aufbauenden Tools benutzt. 🙁
Also, inzwischen habe ich auf dem RootDS und meiner lokalen Gateway-Maschine ein nahezu identisches Debian Lenny Setup. Auf dem RootDS läuft KVM (die Version von Lenny, also Aufruf nur mit vdekvm möglich), auf der lokalen Gateway-Maschine habe ich die neuesten Versionen von QEMU+KQEMU (mit VDE-Support) selbst kompiliert, denn diese Maschine hat leider keine HVM-Extension, und die QEMU Version 0.9.1in Lenny hatte keinen virtio-Support.
Jetzt stellt sich mir gerade die Frage, ob es eine schlechte Idee ist, die VMs als root zu starten. Ich meine, was hat das für einen Einfluß, ob eine VM nun als root oder normaler User läuft?
Ok, das was ich gerade im anderen „Thread“ als Kommentar geschrieben habe, paßt eigentlich besser hierher:
Wie kommt man aus dem qemu-monitor via telnet wieder raus, ohne die QEMU/KVM-Instanz zu beenden? Ich stehe da gerade echt voll an. Alle gängen Tastenkombinationen haben keine Wirkung, und das einzige zur Verfügung stehende qemu-monitor-Kommando („quit“ bzw. „q“) killt den ganzen Prozess.
Aus einer Terminal-Session kannst Du in der Regel mit Ctrl+5 einen Prompt schalten. Der sieht dann so aus:
terminal>
Da kannst Du dann einfach quit eingeben und Enter. Fertig 🙂
So, heute habe ich den letzten Intrepid-Gast auf Jaunty aktualisiert. Jetzt laufen bei mir definitiv _alle_ Gäste unter Jaunty. Auch das Hostsystem selbst. Wenn es da also wirklich Probleme bei Euch geben sollte, müssen die wo anders liegen.
We „integrated“ libvirt and vde using the following procedure:
a) change kvm emulator in libvirt-xml configuration to point to your own script, e.g.:
/usr/local/service/gatkvm
b) use your own script to add or modify whatever parameter you need, we used:
#!/usr/bin/perl
$kvm=“/usr/bin/kvm“;
if (grep(/winxp1/,@ARGV)) {
$kvm=“/usr/bin/vdekvm“;
push(@ARGV,“ -net nic,model=rtl8139,macaddr=56:44:45:30:30:32,vlan=0″);
push(@ARGV,“ -net vde,sock=/var/run/vde2/vde1.ctl vlan=0″);
# print „yes\n“;
}
elsif (grep(/winxp2/,@ARGV)) {
$kvm=“/usr/bin/vdekvm“;
push(@ARGV,“ -net nic,model=rtl8139,macaddr=56:44:45:30:30:34,vlan=0″);
push(@ARGV,“ -net vde,sock=/var/run/vde2/vde1.ctl vlan=0″);
}
exec($kvm,@ARGV);
Greetings
Christoph
Das Skript wurde wieder einmal überarbeitet. Nur kleiner Fixes und der Tausch von telnet zu socat. Bitte auch mal beim Artikel „KVM twekas“ hier im Blog gucken, da ist ein Beispiel für einen Gast.
Ferner habe ich ein Open-Source-Projekt gegründet „kvmnanns“; ein netzwerkbasierter KVM-Installer. Dieser unterstützt ebenfalls das File-Format, was ich bevorzuge 🙂
Bleibt dran… und viel Spaß
Zumindest unter Debian 6 „Squeeze“ funktioniert der socat Befehl zum Herunterfahren der vm so nicht.
Dein Script generiert:
—
echo „system_powerdown“ | socat – 127.0.0.1
—
Es müsste aber lauten:
—
„echo „system_powerdown“ | socat – TCP:127.0.0.1:2023″
—
Port natürlich je nach definiertem Monitoring Port.
Die betreffende Zeile sieht dann so aus:
—
instance_sock=$(echo $var1 | cut -d „,“ -f 1)
—
Der Rest funktioniert einwandfrei, danke dafür 🙂
Dennis
Hi, danke schon mal für Dein Feedback. Ich muss mir das noch mal genauer ansehen, da ich selbst das Problem noch gar nicht hatte. 🙂
Hallo Christian,
glückwunsch ein sehr schönes und genial einfaches Script. Genial weil ich heute etwas dazugelernt habe. Das Komando socat war mir bislang unbekannt. Damit Befehle in einem TCP Socket zu senden und dabei eine VM sauber herunterzufahren ist cool.
Allerdinsg habe ich einen Fehler in deinem Script gefunden in Zeile 104
instance_sock=$(echo $var1 | cut -d “ “ -f 1 | cut -d „,“ -f1 | cut -d „:“ -f2)
Damit schneidest du zu viel ab und der socat schaut dann so aus:
echo „system_powerdown“ | /usr/bin/socat – 127.0.0.1 > /dev/null 2>&1
Error:
2011/03/24 23:20:43 socat[30125] E unknown device/address „127.0.0.1“
Ich habe die Zeile 104 wie folgt geändert:
instance_sock=$(echo $var1 | cut -d “ “ -f 1 | cut -d „,“ -f1)
Ergebnis ist dann:
echo „system_powerdown“ | /usr/bin/socat – tcp:127.0.0.1:5800 > /dev/null 2>&1
Dies Funktioniert dann auch super, und die Windows VM fahren wieder sanft herunter.
Meine Antwort hat etwas länger gedauert. Bitte um Verzeihung. Das Problem wurde erkannt und ich habe den Artikel oben aktualisiert. Dort wird nun klar, warum diese genannten Probleme bei mir gar nicht aufgetreten sind.
Hallo Christian
Hab mal wieder deine Seite aufgesucht… Und hab mir einiges an Input geholt. Das neue Script ist nicht schlecht… ich verwende immer noch das alte und bin sehr zufrieden damit.
was ich gesehen habe, ist, dass Du mit Nice und ionice arbeitest. Den ionice könntest Du ersetzen durch den deadline Scheduler. Der ist effektiver als der cfq Scheduler (bei KVM Hosts). In den Gästen kann dann der deadline oder noop Scheduler verwendet werden. Somit hast du die IO-Performance erheblich gesteigert.
Die Idee den Monitor auf ein UnixSocket zu legen finde ich nicht schlecht und erspart den Telnet. Ich werde diese Idee in mein Script übernehmen finde ich an und für sich die bessere und vernüftigere Lösung.