Eintrag von 2009-08-08
▶ Gentoo: kleine Sorgen mit libvirt
Ich arbeite seit einiger Zeit an einer schlanken Gentoo-Stage4 speziell zum Verwalten von virtuellen Maschinen. Zum Einsatz kommen dabei der Virtualisierungs-Management-Daemon libvirt, sowie der in den Linux-Kernel integrierte Hypervisor KVM. libvirt bietet eine stabile API zum Ansteuern verschiedener Hypervisoren, und hat sich für mich bereits in der Vergangenheit bewährt. KVM selbst nutze ich sogar auf dem Desktop täglich, denn virtuelle Gastsysteme sind aus meinem Alltag aus verschiedensten Gründen kaum noch wegzudenken.
Unter Gentoo genießen beide (Red Hat-)Produkte gute Unterstützung: die neuesten KVM-Releases finden sich immer rasch im Gentoo Repository, auch "Portage Tree" genannt, und libvirt wird ebenfalls in diesen Hauptpaketquellen angeboten.
Wie es sich für anständige Enterprise-Software gehört, ist libvirt natürlich netzwerkfähig. Für libvirt gibt es etwa die beiden Frontends virsh und virt-manager, die sowohl lokal als auch auf anderen Hosts im Netzwerk laufende libvirtd-Instanzen steuern können. Dazu greifen die Programme lokal auf zwei UNIX-Sockets zu, um Befehle an den libvirt-Server abzusetzen, und dessen Antworten zu empfangen. Geht es daran, auf einen libvirt-Server auf einem anderen Computer im Netzwerk zuzugreifen, so kann man zwischen einer in libvirt eingebauten SASL-Authentifikationsmethode und dem weitverbreiteten SSH-Protokoll wählen. Entscheidet man sich für letztere Möglichkeit, starten virsh und virt-manager einfach einen am lokalen System installierten SSH-Client, forwarden damit ein paar Ports des Zielsystems zum lokalen Rechner, und starten auf dem Remote-Host das gute alte netcat, um die schon erwähnten UNIX-Sockets ans Netzwerk zu bringen.
Genau hier beginnen die Probleme bei Gentoo: während es nämlich auf dem lokalen System mittels virsh ein Leichtes ist, virtuelle Maschinen zu verwalten, schlägt es über das Netzwerk (mit Gentoo als Zielsystem) fehl. Das graphische Werkzeug virt-manager wirft dann kryptische Fehlermeldungen aus seinen Python-Innereien, und lässt den User ziemlich ratlos im Dunkeln tapsen. virsh hingegen schafft, wie es sich für eine anständige CLI-Anwendung gehört, sofort Klarheit:
user@some-host:~$ virsh -c "qemu+ssh://remoteuser@gentoo-libvirt-host/system" Connecting to uri: qemu+ssh://remoteuser@gentoo-libvirt-host/system nc: invalid option -- 'U' nc -h for help libvir: Remote error : socket closed unexpectedly error: failed to connect to the hypervisor
Die in Gentoo enthaltene netcat-Version unterstützt die von libvirt-Anwendungen vorausgesetzte Option "-U" (zum Ansprechen von lokalen UNIX-Sockets) nicht. Beim Aufruf des Programms mit der in virsh und virt-manager kodierten Parameterliste beendet sich dieses artig mit einer kurzen Usage-Meldung, die virt-manager aber unterschlägt. Gentoo bietet im Portage Tree immerhin drei Implementationen von netcat: net-analyzer/gnu-netcat, net-analyzer/netcat und net-analyzer/netcat6. Das ebuild von libvirt setzt allerdings zwingend die Installation von net-analyzer/netcat voraus, welches offensichtlich nicht alle Features bietet, die von libvirt auch benötigt werden. Auch gnu-netcat versagt mit dem Switch "-U" seinen Dienst. Nur netcat6 weiß damit etwas Sinnvolles anzufangen. Allein, im System installiert es sich nicht unter dem wohlbekannten Namen nc, sondern unter nc6 - womit virsh und virt-manager ebenfalls nichts anfangen können. Dieses Problem lässt sich allerdings durch einen entsprechenden Symlink (cd /usr/bin && ln -s nc6 nc) schnell beheben.
Eine dauerhafte Lösung kann das freilich nicht sein. Bei Gentoo wird man sich überlegen müssen, ob man das vorhandene netcat-ebuild austauscht, sodass es eine taugliche Version des Programms installiert, oder doch lieber gleich auf netcat6 umsteigen möchte. Dann muss aber natürlich auch der Name der aus dem ebuild resultierenden Binary entsprechend geändert werden. Bis sich dieses Problem ausgewachsen hat, werden sich wohl noch einige User an Gentoos Version des "networking Swiss-army knife" unangenehm schneiden.
direkter Link ▲© 2007-2020 Johannes Truschnigg | valid xhmtl & css