Rößner-Network-SolutionsHeute habe ich nach etlichen Stunden herausgefunden, wie ich KVM-Gäste an VDE-Switches hängen kann. Das Resultat sieht gut aus. Ich verwende Ubuntu Intrepid und installierte vde2 und kvm.
Es gibt auch ppa.launchpad-Repositorien, die neuere KVM-Versionen (zu diesem Zeitpunkt Version 74) zur Verfügung stellen. Diese Version hat bereits VDE im KVM-Binary integriert. Aber nach unzähligen Stunden konnte ich diese Version nicht an 2! Switches anschlieesen. Siehe hierzu:
http://ubuntuforums.org/showthread.php?p=6294558#post6294558
Im Endeffekt nutze ich nun das Wrapperskript vdekvm. Hier beispielhaft eine Konfigurationsdatei:
#!/bin/bash
vdekvm -m 256 -smp 2 \
-name db \
-boot c \
-drive file=/dev/mapper/vg01-kvm2--disk,if=virtio,boot=on \
-net nic,vlan=0,macaddr=00:16:3e:bf:e6:bc,model=virtio \
-net nic,vlan=1,macaddr=00:16:3e:bf:e6:bb,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:1 \
-daemonize
exit 0
Diese verwendet vde0 als internen Switch und vde1 als externen. Die Konfiguration hierfür sieht bei mir wie folgt aus:
# Intranet
auto vde0
iface vde0 inet static
address 10.1.0.1
netmask 255.255.255.0
broadcast 10.1.0.255
vde2-switch -
post-up /sbin/iptables -t nat -A POSTROUTING -j SNAT -o eth0 -s 10.1.0.0/24 \
--to-source 85.10.196.195
pre-down /sbin/iptables -t nat -D POSTROUTING -j SNAT -o eth0 -s 10.1.0.0/24 \
--to-source 85.10.196.195
# External net
auto vde1
iface vde1 inet static
address 78.46.253.225
netmask 255.255.255.248
broadcast 78.46.253.231
vde2-switch -
Vielleicht werde ich den externen Switch noch etwas modifizieren, um eine weitere IP-Adresse gewinnen zu können.
[Update]
Ich hätte gerne mal slirpvde getestet, aber es ist fehlerhaft. Schade. So gesehen kann ich vorerst leider nicht auf eine weitere freiwerdende IP-Adresse hoffen.
[Update-1]
slirpvde funktioniert nun. Ich denke aber, dass es noch etwas Zeit dauert, bis es ausgereift ist. Näher möchte ich jetzt nicht darauf eingehen. Evtl. einfach mal selbst ausprobieren.
[Update-2]
Auf Wunsch stelle ich hier _kurz_ meine aktuelle Konfiguration vor:
Als erstes definiere ich einen internen Switch:
# Intranet switch
auto vde0
iface vde0 inet manual
pre-up mkdir -p /var/run/vde2
up /usr/bin/vde_switch -s /var/run/vde2/vde0.ctl -m 660 -g vde2-net \
-p /var/run/vde2/vde0.pid -M /var/run/vde2/vde0.mgmt --mgmtmode 660 -d
down kill -TERM $(cat /var/run/vde2/vde0.pid)
Nun verbinde ich den Gastgeber mit dem Switch
# Intranet cable to switch
auto vtap0
iface vtap0 inet static
address 10.1.0.1
netmask 255.255.255.0
pre-up vde_tunctl -u vde2-net -t vtap0
up vde_plug2tap -s /var/run/vde2/vde0.ctl --port=1 -g vde2-net \
-P /var/run/vde2/vtap0.pid -d vtap0
down kill -TERM $(cat /var/run/vde2/vtap0.pid)
post-down vde_tunctl -d vtap0
Und das Gleiche noch mal mit einem Switch für das externe Netz und der dazugehörigen Verbindung
# External switch
auto vde1
iface vde1 inet manual
pre-up mkdir -p /var/run/vde2
up /usr/bin/vde_switch -s /var/run/vde2/vde1.ctl -m 660 -g vde2-net \
-p /var/run/vde2/vde1.pid -M /var/run/vde2/vde1.mgmt --mgmtmode 660 -d
down kill -TERM $(cat /var/run/vde2/vde1.pid)
# External cable to switch
auto vtap1
iface vtap1 inet static
address 78.46.253.225
netmask 255.255.255.248
broadcast 78.46.253.231
pre-up vde_tunctl -u vde2-net -t vtap1
up vde_plug2tap -s /var/run/vde2/vde1.ctl --port=1 -g vde2-net \
-P /var/run/vde2/vtap1.pid -d vtap1
down kill -TERM $(cat /var/run/vde2/vtap1.pid)
post-down vde_tunctl -d vtap1
Da hier nun eine Trennung von Switch und Kabel vorliegt, können die Gäste gezielt auf festgelegt Ports gesteckt werden. Beispiel:
…
-net vde,vlan=0,sock=/var/run/vde2/vde0.ctl,port=11 \
…
Ich finde diese Trennung sinnvoller, als die Konfiguration innerhalb Debians (Ubuntu auch), weil hier der Unterschied zwischen den Switches und den dazugehörigen Switches klarer ist. Außerdem kann ich auch mal eine Verbindung zum Switch kappen, ohne das davon gleich die Gäste betroffen sind.
Wenn man dann will, kann man das vtap1-Device zusammen mit eth0 in eine Bridge packen. Dann gewinnt man noch die IP-Adresse für die Verbindung zum Switch. Aber bitte nicht fragen, ob dann noch irgendwelche weiteren Einstellungen notwendig sind. 🙂 Ich weiß es im Moment nicht. Getestet habe ich das einmal und es ging. Aber mir ist ein sauberes Setup lieber und da spendiere ich dann auch gerne noch mal eine weitere IP.
Ich hatte das gleiche Problem. Es scheint, wie auch immer, an „-net nic,model=virtio…“ zu liegen. Mit „model=e1000“ klappt es.
Beste Grüße
Robert
croessner, wie genau setzt Du in diesem Setup diesen externen VDE Switch ein? Wie wird die Verbindung zw. eth0 und vde1 hergestellt (ist da noch eine Bridge im Spiel?)? Was wolltest Du da modifizieren, um eine weitere IP Adresse zu gewinnen? Mir ist schon klar, daß Du auf diese Weise die verfügbaren IPs Deines /29er-Subnetzes Deinen geswitchten VMs zur Verfügung stellen willst (im Gegensatz zum Standard-Setup mit einer einfachen Bridge), aber mir scheinen da noch ein paar Puzzle-Steine zu fehlen, um dieses Vorhaben nachempfinden zu können.
Also im Moment wird das Netz ja einfach geroutet. Da braucht es ja keine Bridge für. Man kann eine Bridge erzeugen und dann eth0 und vde1 dort einbinden. Das habe ich getestet und Du gewinnst dann eine IP.
Ganz aktuell habe ich es sogar noch etwas anders konfiguriert und nutze nicht die Debian-vereinfachungen. Da ich aber gerade von meiem Handy aus schreibe, kann ich das in der Sekunde nicht genauer darstellen. Ich zeige gerne morgen mal meine derzeitige Version. Die ist logisch sauberer und besser nachvollziehbar.
Das würde mich schon sehr interessieren, wie Du das gelöst hast. Da ich bei Hetzner einen neuen EQ4 habe, bei dem leider kein /29er-Subnetz mehr kostenlos inkludiert ist, sondern zur Haupt-IP nur noch drei weitere einzelne IP-Adressen, werde ich in dem Setup alle 4 IP-Adressen auf eth0 lassen, und dann in das geswitchte private Subnetz natten, also nur ein VDE Switch für das virtuelle LAN. Allerdings wird Dein Lösungsansatz mit dem externen VDE Switch spätestens dann aktuelle, wenn ich mich mal dazu entscheiden sollte, das Flexipack und ein Subnetz hinzuzunehmen.
So, meine aktuelle Konfiguration ist drin 🙂 Ich weiß nicht mehr, ob ich für die Bridge-Variante noch irgendwas machen musste. Glaube aber nicht. Ich empfehle es Dir aber so zu belassen, wie ich es oben beschrieben habe. Zumindest läuft das jetzt so schon recht lange 😉
Die neue Version lässt zukünftige Spielerein wie VLANs im Switch zu. Das kommt dann auch noch irgendwann, wenn ich nochmal Zeit finde. Dann fliegt nämlich ein Switch raus.
Zwei weitere Fragen, zu denen ich einfach keine Antworten finden konnte:
1. Wenn man KVM mit VDE einsetzt, und die VMs mangels VDE Unterstützung von libvirt mit eigenen Skripten verwaltet, kann man dann trotzdem libvirt installieren, und z.B. mit virt-manager die VMs überwachen, ohne dass libvirt dieses Setup beeinträchtigt?
2. Ist es weiterhin so, dass “-net nic,model=virtio“ nur funktioniert, wenn man lediglich einen Netzwerkadapter pro VM definiert? D.h. wenn man nur einen internen VDE Switch einsetzt, jede VM nur ein Netzwerkdevice hat, bleibt man bei virtio wegen der besseren Performance, und wenn man zwei Netzwerkdevices haben will, muss man dann beide auf e1000 umstellen, lediglich eines der beiden, oder kann man beide auf virtio lassen?
Zu1.: Ich wüsste ad hoc nicht, wie Du das hinbekommen willst. Aber ich nutze auf dem Gastgeber nfsen und demnächst dann auch Nagios. Zusammen habe ich dann mindestens diesen Funktionsumfang.
Zu 2.: Hier meine www-Instanz:
vdekvm \
-m 512M \
-smp 2 \
-name www \
-boot c \
-drive file=/dev/mapper/vg01-kvm3–disk,if=virtio,boot=on \
-drive file=/dev/mapper/vg01-kvm3–netflow,if=virtio \
-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 \
-vnc 172.18.100.253:3 \
-monitor tcp:127.0.0.1:2323,server,nowait \
-serial none \
-parallel none \
-localtime \
-daemonize > /dev/null 2>&1
Geht also auch mit mehreren virtios. Es funktioniert halt nur mit Linux (weil der virtio-Treiber beim letzten Testen von Windows völlig instabil war).
Ja, war eigentlich klar, dass man dann libvirt total vergessen kann. Einfach zu dumm, dass libvirt weiterhin kein VDE unterstützt.
Ohne libvirt wird es natürlich entsprechend aufwendig. Wie könnte denn dazu das passende nfsen + nagios Setup aussehen?
So, meine ersten Versuche mit KVM+VDE, und kläglich am Scheitern… 🙁
Also ich habe vde0 & vtap0 exakt so eingerichtet, wie Du es oben bei Update-2 mit Deiner aktuellen Konfiguration gezeigt hast. Mit vde0 & vtap0 ist auch alles in Ordnung. Um die erste VM einzurichten, habe ich folgendes Skript namens db.sh erstellt:
#!/bin/sh
vdekvm -m 1024 -smp 2 \
-name db \
-drive file=/dev/vg0/db-root,if=virtio \
-drive file=/dev/vg0/db-var,if=virtio \
-drive file=/root/vmsetup/ubuntu-9.04-server-amd64.iso,media=cdrom,boot=on \
-net nic,vlan=0,macaddr=DE:AD:BE:EF:27:12,model=virtio \
-net vde,vlan=0,sock=/var/run/vde2/vde0.ctl \
-k de \
-vnc 127.0.0.1:0
Beim Aufruf dieses Skripts kommt folgende Fehlermeldung:
# ./db.sh
arg ,vlan=0,sock=/var/run/vde2/vde0.ctl
TUNGETIFF ioctl() failed: Invalid argument
Und zeitgleich zeigt das Kernel-Log folgende Einträge:
Jul 10 01:20:30 masterds1 kernel: [23472.898163] kvm: 8550: cpu1 unhandled wrmsr: 0xc0010117 data 0
Jul 10 01:20:30 masterds1 kernel: [23472.898526] kvm: 8550: cpu0 unhandled wrmsr: 0xc0010117 data 0
Nach der Fehlermeldung gegoogelt, wird geraten, den nativen VDE Support von kvm zu nutzen, also statt vdekvm nur noch kvm einzugeben, zumal der Wrapper bereits deprectated sei. Wenn ich das mache, kommt:
# ./db.sh
Unknown network device: vde
Das weist darauf hin, dass kvm ohne VDE-Support kompiliert wurde. Ich habe ich am Host Ubuntu Server 9.04 laufen:
# kvm
QEMU PC emulator version 0.9.1 (kvm-84)
# uname -a
Linux masterds1 2.6.28-13-server #45-Ubuntu SMP Tue Jun 30 22:56:18 UTC 2009 x86_64 GNU/Linux
Das kann doch gar nicht sein, oder? Muss ich jetzt wirklich kvm von Hand mit VDE-Support kompilieren?
Das ist genau das Problem bei Debian und Ubuntu, dass leider der Support fehlt. Die vermeindlichen Fehlermeldungen habe ich mit dem Wrapperscript auch, dass macht aber nichts aus. Hier funktioniert es trotzdem.
Das Problem bei Dir muss also folglich leider ein anderes sein
Welche Distribution hast Du denn im Einsatz?
Nochmal Hallo,
sorry, aber würde Dir das etwas ausmachen, Dei Problem nochmal im Forum zu posten? Ich wollte die Kommentare hier gerne etwas bescheidener halten. Würde mich total freuen, wenn das Forum interesse findet. Ist noch „jungfräulich“ und daher muss es halt erst angenommen werden. Ich werde aber ganz sicher dort auch antworten.
Vielleicht dann auch andere Mitglieder.
Oh, gar nicht gesehen, dass es hier auf ein Forum gibt. 😉
http://forums.roessner-net.com/viewtopic.php?f=4&t=6
Ich hatte heute eine scheinbar revolutionäre Idee für einen Workaround, um VDE zusammen mit libvirt benutzen zu können:
VDE wie oben von Dir unter [Update-2] beschrieben mit vde0 & vtap0 einrichten. Dann im XML File für die VM das Netzwerkinterface folgendermaßen setzen:
und in /etc/kvm/kvm-ifup-db dann:
#!/bin/sh
sudo vde_tunctl -u vde2-net -t vtap1
sudo vde_plug2tap -s /var/run/vde2/vde0.ctl -g vde2-net \
-P /var/run/vde2/vtap1.pid -d vtap1
Also von libvirt ein generisches Ethernet-Device erstellen lassen (wie unter http://libvirt.org/formatdomain.html#elementsNICSVirtual beschrieben), und dann per Skript an den internen VDE Switch anschließen.
Sieht für mich logisch aus, funktioniert aber nicht. Beim Start der VM wird kein „vtap1“ Device angelegt, und selbst wenn man „vde_tunctl -u vde2-net -t vtap1“ manuell ausführt, kommt als Rückmeldung nur „TUNSETIFF: Device or resource busy“.
Wenn libvirt schon die Möglichkeit bietet, ein generisches Ethernet-Device zu erzeugen, und dann auch noch ein dazu passendes Skript ausführen kann, sollte das doch nicht so schwierig sein, das irgendwie unter einen Hut zu bringen.
Was sagst Du dazu?
Ups, erst lesen, dann posten… Da oben fehlt folgender Teil nach „Dann im XML File für die VM das Netzwerkinterface folgendermaßen setzen:“
Damned, der Teil aus der XML Datei läßt sich hier 1:1 nicht posten, und verschwindet einfach spurlos aus dem Text. Also ich schreibe das jetzt nochmals ohne die Begrenzungen:
interface type=’ethernet‘
mac address=’de:ad:be:ef:27:12’/
script path=’/etc/kvm/kvm-ifup-db’/
target dev=’vtap1’/
model type=’virtio’/
/interface
Dem Grunde nach gebe ich Dir recht. Nur habe ich das Skript _auch_ aus einem anderen Grund geschrieben: Ich kann auf einem Server nicht die Reihenfolge angeben, in der Gäste gestartet werden sollen. Auch nicht, wie lange dann ein Gast auf den anderen warten soll, bis er startet. Das ist auf einem Setup wie meinem aber essentiell wichtig. Ich habe einen Datenbankserver, der als erstes gestartet werden muss, danach folgt der DNS-Server. Diese beiden müssen unbedingt sauber oben sein, bevor weitere Gäste gestartet werden dürfen. Nur aus diesem grund habe ich das Skript entwickelt. Die Idee eines Startscripts für libvirt hatte ich zuvor auch schon 😉
Ja, hast recht, ich bin nun auch endgültig von der Idee mit libvirt abgekommen. Ich habe kurzerhand den Rootserver mit Debian Lenny neu aufgesetzt, und siehe da, KVM+VDE hat auf Anhieb geklappt. Bei Lenny its zwar nur kvm-72 mit dabei, und unterstützt wiederum kein VDE nativ, aber diesmal hat der Start mit vdekvm einwandfrei geklappt. Ich denke, ich habe jetzt endgültig die Nase voll von Ubuntu, d.h. back to the roots. Ich muss jetzt erst noch meinen SOHO-Gatewayserver neu aufsetzen (ebenfalls Debian Lenny), und dann den Rootserver per VPN anbinden, bevor ich mit der Installation der VMs weitermache. 🙂
Ich bin immer etwas vorsichtig, wenn es darum geht „die Schuld“ mal eben auf eine Distribution zu schieben. Ich für meinen Teil z.B. setze komplett auf Ubuntu. Ich habe einige Server unter Ubuntu mit genau der gezeigten Konfiguration problemlos und stressfrei am Laufen. So leid es mir tut, aber ich vermute, dass Du dann vielleicht selbst irgendwo einen Fehler eingebaut hattest. Aber Lenny ist auch gut 😉
Hast Du Deine erfolgreichen Installationen mit Ubuntu Jaunty am Laufen? Ich nehme mal stark an, dass Du für Deine Server weiterhin Intrepid einsetzt, und mit Jaunty ganz einfach etwas nicht stimmt. Ich habe ausgehend von einer Minimal-Installation mit Debian Lenny und Ubuntu Jaunty exakt die gleichen Schritte bis zum Start von KVM mit VDE-Setup vollzogen, und mit Ubuntu ist oben beschriebener ShowStopper aufgetreten, mit Lenny eben nicht. Bei Jaunty ist leider wieder mal der Murks drin, das habe ich auch schon an anderen Stellen bemerken müssen. Natürlich ist Lenny ebenfalls nicht perfekt, aber ich nehme mal stark an, dass die Betriebsystem-Basis bei Debian einfach besser abgestimmt ist. Ich bin übrigens letztens auf http://fishbowl42.com/blog/ gestossen, und bin nun stark in Versuchung, auf ein Desktop Setup mit Debian Lenny + XFCE 4.6.1 + Firefox 3.5 zu wechseln… 😉
Ist mittlerweile schon ganz schön unübersichtlich hier, ein Blog ist einfach nicht der richtige Ort für weitreichende Diskussionen. Ich denke, wir benötigen ein KVM+VDE Forum, Urs wird ja sicherlich auch wieder zu uns stoßen, sobald er sein Base-Setup fertig hat. Bin schon gespannt, ob er seine Idee mit einem eigenen Wiki umsetzt.
Das Host-System ist Jaunty. Die Gäste Intrepid. Geht aber auch problemlos mit Jaunty-Gästen. So zum Beispiel auf meiner Workstation. Jaunty-Host und Jaunty-Gast.
Dann muss meine Maschine verhext sein! Ich meine, so blöd kann man sich doch gar nicht anstellen. Ein und dasselbe Setup mehrmals nacheinander mit Jaunty vollzogen, immer derselbe Fehler („TUNGETIFF ioctl() failed: Invalid argument“), dann exakt dasselbe Setup mit Lenny, und der Fehler trat nicht auf. In Bezug auf KVM selbst spielt es keine Rolle, ob Lenny oder Jaunty, da beide Versionen leider ohne nativen VDE-Support kompiliert wurden, was natürlich Keks ist, denn die Verwendung des Wrappers „vdekvm“ ist deprecated.
Also zu Deiner Fehlermeldung: Die ist völlig irrelevant. Die habe ich auch. Das macht aber gar nichts. Es bedeutet ja nur, dass der Kernel über ein bestimmtes Feature nicht verfügt. Trotzdem läuft der Kram hier. Nicht ohne Grund leite ich die Fehlerausgabe nach /dev/null
🙂 Dein Rechner ist nicht verhext
Also die Ausgabe von „arg ,vlan=0,sock=/var/run/vde2/vde0.ctl“ beim Starten der VM ist jedenfalls mal normal, das macht’s unter Lenny auch. Aber ”TUNGETIFF ioctl() failed: Invalid argument” erwies sich als ShowStopper. Im Inet gibt es zu exakt diesem Fehler kaum Info, außer eben daß es darauf hinweist, daß das virtuelle Netzwerkdevice für die VM nicht erzeugt werden konnte, was in meinem Fall auch gestimmt hat, denn ein check mit unixterm /var/run/vde2/vde0.mgmt -> port/print hat gezeigt, daß kein weiterer Port am VDE belegt wurde. Wie schon erwähnt, keine Ahnung, was da los war, der Fehler lies sich mehrmals nacheinander reproduzieren, weswegen ich dann ja auch aufgegeben, und zu Lenny gewechselt habe. Total rätselhaft, wenn derselbe Fehler bei Dir auch auftritt, es aber dennoch funktioniert.
cat jaunty01
#!/bin/sh
TIME_TO_WAIT=0
# export QEMU_AUDIO_DRV=pa
# export QEMU_AUDIO_LOG_TO_MONITOR=1
vdekvm \
-m 192M \
-smp 1 \
-name jaunty01 \
-boot c \
-drive file=/dev/vg01/lv_ldapslave,if=virtio,boot=on \
-net nic,vlan=0,macaddr=00:16:36:58:f5:65,model=virtio \
-net vde,vlan=0,sock=/var/run/vde2/vde0.ctl,port=10 \
-vnc 127.0.0.1:2 \
-monitor tcp:127.0.0.1:2023,server,nowait \
-serial none \
-parallel none \
-localtime \
-pidfile /var/run/kvm/jaunty01.pid \
-daemonize # > /dev/null 2>&1
# vim: ts=2 sw=2 expandtab
arg ,vlan=0,sock=/var/run/vde2/vde0.ctl,port=10
TUNGETIFF ioctl() failed: Invalid argument
ps auxc | grep kvm
root 7285 0.0 0.0 19072 308 ? Ss 15:58 0:00 vdekvm
root 7288 24.7 2.8 526768 114180 ? Sl 15:58 0:10 kvm
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
Mehr kann ich Dir nicht sagen
Ich hab mich heut auch die ganze Nacht mit KVM und VDE unter Ubuntu Jaunty rumgeschlagen.
Master One’s posts sprechen mir gerade aus der Seele – ich hab’s unter Ubuntu gerade auch quasi aufgegeben.
Wurde inzwischen irgendwo weiterdiskutiert oder könnten wir sonst wie Kontakt zu dem Thema aufnhemen?
Gruss
Markus
Nö, wurde noch nicht weiter diskutiert. Kann aber hier (vorerst) weiter stattfinden. 🙂
Ich denke ich werds heut Abend/Nacht nochmal unter Ubuntu 9.04 versuchen, und dann hier nochmal genauer posten wie ich es bei mir probiert habe!
Vorweg nochmal bitte folgende kurze Fragen zu Klärung:
Du hast also als Host auch Ubuntu 9.04, und nutzt hierauf dein Init-Skript in Kombination mit den Gast-Scripten die vdekvm als Wrapper benutzen?
Den vde-switch startest Du ähnlich wie in deinem Artikel zu XDMCP im ‚interfaces‘ file zu sehn?
Der TUNGETIFF Fehler tritt bei Dir auch auf – es funktioniert aber trotzdem (Jaunty Bug?)?
Korrekt so? 🙂
Du hast Dich wie ich gesehn habe schon ziemlich intensiv mit dem Thema KVM und VDE beschäftigt und viel Mühe in Deine Scripte und HowTos gesteckt – hätte bestimmt noch die ein oder andere Frage an Dich 🙂
Soll ich Dich vielleicht besser mal per Mail kontaktieren und/oder bist Du im IRC unterwegs?
Grüße
Also eigentlich kann ich nur zu allen Fragen JA sagen 😉
Mal eine Frage: Das Skript nutzt ja Gast-Skripten, um diese damit zu starten und zu stoppen. Wenn Du in einem der Gast-Skripten einfach mal die letzte Option -daemonize deaktivierst (# davor) und dann mal auf der Konsole mit
/bin/sh gastscriptname
startest, was spuckt dir dann das System aus?
N.B.: Ich schreibe gerade an meiner Bachelor-Thesis, da kann es mit unter mal etwas dauern, bis ich zum Antworten komme
Heut Nacht hatte ich den Durchbruch.
Im Endeffekt war es wohl Probelm mit meinen Benutzerrechten. Um beim starten des vde_switches ohne sudo auszukommen und möglichen Problemem mit Benutzerrechten aus dem Weg zu gehn hab ich alle nötigen files in meinem home Verzeichnis abgelegt. (Die saubere Rechtevergabe ist mir noch nicht ganz klar – müsste wohl noch von mir verbessert werden)
########################################################################
# /etc/network/interfaces sieht jetzt vorerst so aus:
########################################################################
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
up /sbin/ifconfig eth0 promisc
auto vde0
iface vde0 inet manual
up /usr/bin/vde_switch -s /home/markus/vde_network/switches/vde0.ctl -m 666 -p /home/markus/vde_network/switches/vde0.pid -M /home/markus/vde_network/switches/vde0.mgmt –mgmtmode 666 -d
down kill -TERM $(cat /home/markus/vde_network/switches/vde0.pid)
auto vtap0
iface vtap0 inet manual
pre-up vde_tunctl -t vtap0
up vde_plug2tap -s /home/markus/vde_network/switches/vde0.ctl –port=1 -P /home/markus/vde_network/switches/vtap0.pid -d vtap0
post-up /sbin/ifconfig vtap0 promisc
down kill -TERM $(cat /home/markus/vde_network/switches/vtap0.pid)
post-down vde_tunctl -d vtap0
auto extbr0
iface extbr0 inet dhcp
bridge_ports eth0 vtap0
bridge_maxwait 0
########################################################################
# beispiel start-script
########################################################################
#!/bin/sh
vdekvm -m 512 -smp 1 \
-name test \
-boot c \
-drive file=/home/markus/vde_network/vms/test.img,if=virtio,boot=on \
-net nic,macaddr=00:16:3e:bf:e6:be,model=virtio \
-net vde,sock=/home/markus/vde_network/switches/vde1.ctl,port=2 \
-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
########################################################################
Genau nach deiner Anleitung.
Die Start-Scripte für die VMs hab ich INST_DIR=“/home/markus/vde_network/vms/guests. Einzelne VMs kann ich so auch starten, leider funktioniert das automatische starten noch nicht. hab noch nicht ganz verstanden wie Du dass mit den logischen links in $INST_DIR/rc meinst (bitte nochmal nen Tip hierzu).
Die Fehlermeldung „TUNGETIFF ioctl() failed: Invalid argument“ taucht nach wie vor auf – Verbindung funktioniert aber! Evtl. liegts am Wrapper vdekvm – ich hab vor mal zu versuchen KVM mit VDE support neuzukopilieren (muss ich erst noch genau ansehn)…
VLANs habe ich mir auch direkt konfiguriert. Beim Start des vde_switch kann mit der Option „-f /home/markus/vde_network/switches/vde1.conf“ den switch direkt konfigurieren.
Hierzu noch eine Frage/Problem: Das tap Interface vtap0 hängt ja zum einen an dem vde_switch vde0 und ist zum anderen auf dem Host an etho gebridged. Sobald ich nun VLANs/Subnetze definiere reicht die einfache Bridge auf dem Host nicht aus um Clients in den VLANs zu finden – ich denke hier besteht dann ein Problem mit dem Routing in die VLANs. Hieran werd ich noch weiterbasteln – ich hoffe meine Frage ist halbwegs verständlich 🙂 – bin schon ziemlich fertig inzwischen…
Ich hoffe das sprengte jetzt nich zu arg den rahmen hier – freu mich schon auf deinen Kommentar 🙂
So weit … Gruss Markus
Schön, ein weiterer Teilnehmer an der Sache. Willkommen im (bislang sehr kleinen) Club. 😉
Also ich habe heute den ganzen Tag damit verbracht, herauszufinden, dass die Option -smp (>1) die Nutzung von KQEMU verhindert (ich benutze nun ein nahezu identisches Debian Lenny Setup auf meinem RootDS & lokalen Firewall-Gateway, wobei der Firewall-Gateway-Rechner leider kein KVM beherrscht). Dieser Umstand ist nämlich nirgendwo dokumentiert…
Mittlerweile habe ich die aktuellste Version von QEMU/KVM auf beiden Maschinen selbst kompiliert, sodaß nun Virtio+VDE nativ unterstützt wird. Mit der neuesten Version von QEMU/KVM 0.11.0-rc1 gibt es übrigens eine Angleichung, d.h. im Endeffekt gibt es nun nur noch QEMU, das eben einerseits mit KVM und/oder KQEMU Support kompiliert werden kann, somit starte ich KVM auf dem RootDS nun auch mit demselben Kommando (qemu-system-x86_64).
Wobei ich gerade anstehe: Wenn man auf den qemu-monitor per telnet zugreift, wie kann man diesen (bzw. diese telnet-Sitzung) wieder verlassen, ohne daß die QEMU/KVM-Instanz beendet wird? Das einzige existierende Kommand im qemu-monitor ist „quit“, damit wird eben QEMU/KVM beendet. Gibt es da irgendeine mir nicht bekannte Tastenkombination? Ich habe mich jetzt viel zu lange erfolglos damit rumgespielt.
Guckst Du mal bei die andere Thread 🙂
Hallo,
ich möchte hier kurz auf das OpenSource-Projekt UnifiedSessionsManager hinweisen,
Ein OpenSource-Toolset zur herstelleruebergreifenden nahtlosen Bedienung und Administration von virtuellen und physikalischen Maschinen.
Die Einrichtung von vde-Netzen fuer QEMU/KVM reduziert sich auf:
fuer root: „ctys-setupVDE create“
fuer userX: „ctys-setupVDE -u userX create“
Dies prueft und erzeugt wenn erforderlich, kann lokal und
remote ausgefuehrt werden:
-> Virtuelle Switches (Xen, etc.)
-> TAP-Device
-> vde_switch
-> Unx-Domain-Sockets
-> Alle Port-IP-Konfigurationen.
Das entfernen erfolgt mit
„ctys-setupVDE cancel“
– Private Clouds – das „Intranet“
Es ist insbesondere für Systemadministration, SW-Entwicklung und
SW/Sytemtest geeignet.
Desweiteren enthalten sind:
Scriptfaehige Kommandozeilen-Schnittstelle, Tools zur automatisierten
Erzeugung, Erfassung, Inventarisierung und Benutzung von verteilten
virtuellen und physikalischen Maschinen.
Siehe:
http://www.UnifiedSessionsManager.org
Mit freundlichen Gruessen
Arno-Can Uestuensoez