Virtualisierung – Wie man Probleme behebt

Markmc, Crobinso, Voxadam Version unspecified Last review: 2018-05-20 Needs a review!
In Bearbeitung!

Diese Seite wurde aus der früheren Fedora Wiki-Dokumentation übernommen.

Der Text wurde für die Veröffentlichung hier im Fedora Docs Portal überarbeitet, aber noch nicht auf technische Korrektheit geprüft.

Verwenden Sie diese Dokumentation derzeit nicht. Möglicherweise

  • enthält sie Formatierungsfehler

  • ist sie nicht mehr aktuell

  • benötigt Zuwendung

Wir freuen uns über Hinweise zur technischen Korrektheit. Wenn Sie mithelfen möchten, finden Sie Anweisungen in der README-Datei im Quellcode-Repository.

Pull Requests werden auf https://forge.fedoraproject.org/docs/quick-docs akzeptiert

Sobald die Seite korrekturgelesen und korrigiert ist, entfernen Sie diese Notiz.

Effektive Fehlermeldungen

Das effektive Melden von Fehlern ist eine wichtige Fähigkeit für jeden Fedora-Benutzer oder -Entwickler.

Durch die Eingrenzung der möglichen Fehlerursachen und die Bereitstellung der richtigen Informationen im Fehlerbericht kann ein Fehler schnell behoben werden. Ein Fehlerbericht mit wenigen hilfreichen Informationen kann dazu führen, dass der Fehler ungelöst bleibt, möglicherweise bis er automatisch geschlossen wird, wenn die Distributionsversion das Ende ihres Lebenszyklus erreicht.

Siehe wie man einen Fehlerbericht einreicht für allgemeineInformationen zum Melden von Fehlern. Diese Seite enthält spezifischeInformationen zu Fehlern im Bereich der Virtualisierung.

Versioninformationen

Sobald Sie sichergestellt haben, dass Sie die neuesten Aktualisierungen installiert haben, sammeln Sie Details zu den Versionsnummern dieser Pakete, zum Beispiel

$ rpm -q qemu-kvm qemu-common python-virtinst virt-viewer virt-manager

Um herauszufinden, welche Kernel-Version Sie aktuell verwenden und welche Rechnerarchitektur Sie nutzen:

$ uname -a

Selbstverständlich sollten Sie den Fehlerbericht auch mit der entsprechenden Fedora-Version einreichen. Rawhide-Nutzer sollten Fehlerberichte mit der „rawhide“-Version einreichen.

Hardware-Informationen

Die Virtualisierungsfähigkeiten von Fedora hängen stark von den Hardwarefähigkeiten ab. Geben Sie daher beim Melden von Fehlern bitte ausführliche Informationen zu Ihrer Hardwareplattform an, einschließlich:

$ cat /proc/cpuinfo
$ lspci -vvv
$ virt-host-validate

Sie können auch überprüfen, welche Virtualisierungsfunktionen auf Ihrem Rechner verfügbar sind, indem Sie Folgendes ausführen:

$ virsh capabilities

Gastsystem-Konfiguration

Wenn Sie einen Fehlerbericht zu Problemen im Gastsystem einreichen, fügen Sie bitte vollständige Details zur Gastkonfiguration bei – einschließlich CPU-Architektur, RAM-Größe, Geräten usw. Dies gelingt am einfachsten, indem Sie die Ausgabe von virsh dumpxml MyGuest oder, im Falle von QEMU, die vollständige QEMU-Befehlszeile beifügen.

Virt Manager

Virt Manager speichert eine Protokolldatei in ~/.cache/virt-manager/virt-manager.log.

Überprüfen Sie die Protokolldatei und fügen Sie alle Abschnitte, die nützlich erscheinen könnten, dem Fehlerbericht bei. Hängen Sie im Zweifelsfall die gesamte Datei an den Fehlerbericht an.

Sie können virt-manager auch über die Befehlszeile mit dem Befehl virt-manager --no-fork starten und überprüfen, ob dort relevante Meldungen ausgegeben wurden.

virt-install

virt-install speichert eine Protokolldatei in ' ~/.cache/virtinst/virt-install.log`.

Führen Sie virt-install mit der Option --debug aus, um detaillierte Debug-Ausgaben zu erhalten.

Um während der Installation Zugriff auf eine serielle Konsole zu erhalten, können Sie -x "console=ttyS0" verwenden. Die Nutzung einer seriellen Konsole in Kombination mit einer VNC-Installation kann für Debugging-Zwecke sehr nützlich sein – zum Beispiel --nographics -x "console=ttyS0 vnc".

libvirt

Jedes Programm, das libvirt verwendet, kann mit Hilfe der Umgebungsvariable LIBVIRT_DEBUG=1 debuggt werden, zum Beispiel

$ LIBVIRT_DEBUG=1 virt-manager --no-fork
$ LIBVIRT_DEBUG=1 virsh list --all

Falls es so aussieht, als könnte Ihr Problem mit libvirtd zusammenhängen, versuchen Sie, in /var/log/messages nach Fehlermeldungen zu suchen.

Sie können auch die /etc/libvirt/libvirtd.conf-Protokollierungs-Konfiguration verwenden, um beispielsweise Debug-Ausgaben in eine Datei zu protokollieren:

log_level = 1
log_outputs = 0:file:/tmp/libvirtd.log

Alternativ könnten Sie versuchen, libvirtd über die Befehlszeile mit aktivierten Debugging-Optionen auszuführen:

$ sudo systemctl stop libvirtd
$ sudo LIBVIRT_DEBUG=1 libvirtd --verbose

libguestfs

Falls libguestfs, guestfish, virt-df usw. Probleme verursachen, führen Sie Folgendes aus:

$ sudo libguestfs-test-tool

Wenn alles funktioniert, sehen Sie gegen Ende der Ausgabe Folgendes:

===== TEST FINISHED OK =====.

Falls etwas nicht funktioniert, posten Sie die vollständige, unbearbeitete Ausgabe dieses Befehls in einem Fehlerbericht.

Netzwerk

Falls Sie Probleme mit Gastsystemen haben, die mit einem virtuellen libvirt-Netzwerk, einer gemeinsam genutzten physischen Schnittstelle oder einer Bridge verbunden sind, versuchen Sie es mit diesen Befehlen:

$ sudo virsh net-list --all
$ sudo brctl show
$ sudo sysctl net.bridge.bridge-nf-call-iptables
$ sudo iptables -L -v -n
$ sudo ps -ef | grep dnsmasq
$ sudo ifconfig -a
$ sudo cat /proc/sys/net/ipv4/ip_forward
$ sudo service libvirtd reload

Falls Sie feststellen, dass /proc/sys/net/ipv4/ip_forward beim Systemstart nicht auf 1 gesetzt wird, überprüfen Sie die Reihenfolge der Dienste libvirtd und NetworkManager:

$ sudo find /etc/rc.d -regex '.*rc[35].d/S.*\(libvirtd\|NetworkManager\)'
$ sudo rm -f /etc/chkconfig.d/libvirtd /etc/chkconfig.d/NetworkManager
$ sudo chkconfig libvirtd resetpriorities
$ sudo chkconfig NetworkManager resetpriorities
$ sudo find /etc/rc.d -regex '.*rc[35].d/S.*\(libvirtd\|NetworkManager\)'

kvm

Siehe auch die [http://www.linux-kvm.org/page/Bugs KVM-Wikiseite über das Melden von Fehlern].

Die Ausgabe eines <code>qemu-kvm</code>-Befehls, ausgeführt von <code>libvirtd</code>, wird in <code>/var/log/libvirt/qemu/GuestName.log</code> gespeichert.

[[Testing_KVM_with_kvm_autotest|kvm-autotest]] ist eine exzellente Möglichkeit zum Testen der grundlegenden KVM-Funktionalität.

Xen

Einige nützliche Informationen zur Fehlersuche bei Xen-Problemen finden Sie auf der Wiki-Seite [http://wiki.xen.org/wiki/Debugging_Xen Debugging Xen]. Sollten Sie der Ansicht sein, einen tatsächlichen Fehler gefunden zu haben, empfiehlt es sich, die Schritte zu befolgen, die entweder auf der Wiki-Seite [http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen Reporting Bugs against Xen] oder in diesem Blogbeitrag beschrieben sind.

Die gemeldeten Fehler, die derzeit von den Xen-Entwicklern nachverfolgt werden, sind im Xen Hypervisor Bug Tracker gesammelt; es lohnt sich daher, dort nachzusehen, ob der von Ihnen gefundene Fehler bereits bearbeitet wird.

Weitere nützliche Informationen:

  • Protokolldateien sind unter <code>/var/log/xen/</code> verfügbar – sowohl für HVM- als auch für PV-Gastsysteme (achten Sie auf den Namen Ihres Gastsystems und die Domain-ID)

  • Falls Ihr Gastsystem abstürzt, empfehlen wir Folgendes:

    • Setzen Sie „on_crash=preserve“ in Ihrer Domain-Konfigurationsdatei

    • Kopieren Sie die System.map des Kernels in den Host

    • Sobald das Gastsystem abgestürzt ist, führen Sie <code>/usr/lib/xen/bin/xenctx -s System.map <domid></code> aus

Allgemeine Tipps

Systemprotokolldateien

Schauen Sie stets in <code>dmesg</code>, <code>/var/log/messages</code> usw. nach nützlichen Informationen.

strace

<code>strace</code> kann oft Aufschluss über einen Fehler geben – wenn man beispielsweise <code>virt-manager</code>, <code>libvirtd</code> oder <code>qemu-kvm</code> unter <code>strace</code> ausführt, lässt sich erkennen, auf welche Dateien zugegriffen, welche Befehle ausgeführt und welche Systemaufrufe getätigt wurden usw.:

<pre> $> strace -ttt -f libvirtd </pre>

Falls das betreffende Programm bereits läuft, können Sie sich mit <code>strace -p</code> daran anhängen.

gdb

<code>gdb</code> kann oft nützlich sein, um die Ausführung eines Programms nachzuvollziehen.Um jedoch verwertbare Informationen zu erhalten, müssen Sie „debuginfo“-Pakete installieren.Weitere Informationen finden Sie auf der Seite .

SELinux

Wenn Sie Meldungen wie „AVC denied“ oder „setroubleshoot“ in <code>/var/log/messages</code> sehen, könnte der Fehler durch ein Problem mit der SELinux-Richtlinie verursacht werden. Versuchen Sie, SELinux vorübergehend in den Modus „permissive“ zu versetzen:

<pre> $> setenforce 0 </pre>

Wenn der Fehler dadurch verschwindet, bedeutet das nicht, dass er tatsächlich behoben ist – es grenzt lediglich die Ursache ein! Sie sollten die AVC-Details aus <code>ausearch -m AVC -ts recent</code> in den Fehlerbericht aufnehmen; falls die Meldung einen <code>sealert -l</code>-Befehl enthält, fügen Sie stattdessen die von diesem Befehl ausgegebenen Details bei.

Eine häufige Ursache für SELinux-Probleme sind falsch gekennzeichnete Dateien. Versuchen Sie Folgendes:

<pre> $> restorecon /Pfad/zur/Datei/in/der/SElinux-Meldung </pre>

Wenn Sie die Installation mithilfe einer ISO-Datei auf einer NFS-Einhängung durchführen, müssen Sie sicherstellen, dass diese mit dem Label <code>virt_content_t</code> eingehängt wird:

<pre> $> mount -o context="system_u:object_r:virt_content_t:s0" …​ </pre>

Wenn Sie libvirt-Storage-Pools (wie NFS) oder USB-Passthrough verwenden, sollten Sie eine der folgenden booleschen SELinux-Konfigurationswerte überprüfen oder umschalten: virt_use_comm, virt_use_fusefs, virt_use_nfs, virt_use_samba, virt_use_usb.

<pre> $> getsebool virt_use_nfs virt_use_nfs -→ off $> setsebool -P virt_use_nfs on </pre>

Fehlerbehebung =

Probleme mit Zugriffsrechten ==

Vor Fedora 11 bzw. libvirt 0.6.1 wurden alle über libvirt ausgeführten virtuellen Maschinen mit Root-Rechten betrieben, was volle Administratorbefugnisse gewährte. Dies vereinfachte zwar die Verwaltung der virtuellen Maschinen, war jedoch aus Sicherheitsaspekten bedenklich: Eine kompromittierte virtuelle Maschine hätte unter Umständen Administratorrechte auf dem Host-System erlangen können.

Mit Fedora 11 und libvirt-0.6.1 verbesserte sich die Sicherheit durch die Einführung von [[Features/SVirt_Mandatory_Access_Control|svirt]]. Kurz gesagt versucht libvirt, automatisch SELinux-Labels auf alle Dateien anzuwenden, die eine VM benötigt – etwa auf Disk-Abbilder. Versucht eine VM, eine Datei zu öffnen, die nicht von libvirt mit einem Label versehen wurde, wird der Zugriff verweigert.

Mit Fedora 12 gab es weitere Verbesserungen. Ab libvirt-0.6.5 wurden VMs mit eingeschränkten Prozess-Capabilities gestartet. Dies verhinderte, dass die VM beispielsweise die Netzwerkkonfiguration des Hosts änderte (eine Aktion, die normalerweise nicht erforderlich sein sollte). Zudem wurde der VM-Emulator-Prozess ab libvirt-0.7.0 standardmäßig nicht mehr als „root“, sondern als privilegienloser „qemu“-Benutzer ausgeführt.

Auch wenn all diese Änderungen der Sicherheit zugutekommen, haben sie zuvor funktionierende Setups beeinträchtigt, die auf die weniger strengen VM-Berechtigungen angewiesen waren. Für die meisten Probleme gibt es zwar Umgehungslösungen, doch gehen diese zulasten der Sicherheit. Langfristig sollten viele dieser Probleme so gelöst werden, dass alles „einfach funktioniert“ – doch so weit sind wir noch nicht.

Ändern des Benutzers des QEMU/KVM-Prozesses

{{admon/warning|Das Ändern des Benutzers für den QEMU/KVM-Prozess hat Auswirkungen auf die Sicherheit.}}

Um den Benutzer zu ändern, unter dem libvirt den QEMU/KVM-Prozess ausführt, bearbeiten Sie die Datei /etc/libvirt/qemu.conf, heben Sie die Auskommentierung der Einträge user= und group= auf und passen Sie diese an. Wenn Sie KVM beispielsweise als Benutzer „foobar“ ausführen möchten, setzen Sie die Felder wie folgt: <pre>…​ user='foobar' group='foobar' …​</pre> Starten Sie anschließend libvirtd mit dem Befehl <pre>service libvirtd restart</pre> neu.

Ändern der SVirt/Selinux-Konfiguration

{{admon/warning|Das Ändern der SVirt-/SELinux-Einstellungen kann Auswirkungen auf die Sicherheit haben.}}

SVirt kann für den libvirt-QEMU-Treiber deaktiviert werden, indem man die Datei /etc/libvirt/qemu.conf bearbeitet, die Zeile <pre>security_driver='none'</pre> auskommentiert (bzw. aktiviert) und entsprechend setzt. Starten Sie anschließend libvirtd mit <pre>service libvirtd restart</pre> neu.

Ändern der Capabilities des QEMU/KVM-Prozesses

{{admon/warning|Das Ändern dieser Einstellung hat Auswirkungen auf die Sicherheit.}}

Standardmäßig startet Libvirt QEMU/KVM-Gäste mit eingeschränkten Prozess-Capabilities. Um diese Funktion zu deaktivieren, bearbeiten Sie die Datei /etc/libvirt/qemu.conf, entfernen Sie das Kommentarzeichen vor der Zeile <pre>clear_emulator_capabilities=0</pre> und setzen Sie diesen Wert. Starten Sie anschließend libvirtd mit dem Befehl <pre>service libvirtd restart</pre> neu.

KVM-Leistungsprobleme

Die Langsamkeit von VMs wird häufig dadurch verursacht, dass die VM einfaches QEMU und nicht KVM verwendet.

Sicherstellen, dass das System KVM-fähig ist

Überprüfen Sie, ob die KVM-Kernelmodule ordnungsgemäß geladen sind:

<pre> $ lsmod | grep kvm kvm kvm_intel </pre>

Wenn dieser Befehl weder kvm_intel noch kvm_amd auflistet, ist KVM nicht ordnungsgemäß konfiguriert. Konsultieren Sie [http://www.linux-kvm.org/page/FAQ#How_can_I_tell_if_I_have_Intel_VT_or_AMD-V.3F| diese KVM-Wiki-Seite], um sicherzustellen, dass Ihre Hardware Virtualisierungserweiterungen unterstützt. Ist dies nicht der Fall, können Sie die KVM-Beschleunigung nicht nutzen; als Option bleibt lediglich das reine QEMU.

Falls Ihre Hardware Virtualisierungserweiterungen unterstützt, versuchen Sie, die Kernelmodule mit folgendem Befehl neu zu laden:

<pre> su -c 'bash /etc/sysconfig/modules/kvm.modules' </pre>

Führen Sie den obigen lsmod-Befehl erneut aus und prüfen Sie, ob Sie die gewünschte Ausgabe erhalten. Falls nicht oder falls der Befehl kvm.modules einen Fehler erzeugt, überprüfen Sie die Ausgabe von:

<pre> dmesg | grep -i kvm </pre>

Falls die Meldung „KVM: disabled by BIOS“ erscheint, konsultieren Sie bitte die [http://www.linux-kvm.org/page/FAQ#.22KVM:_disabled_by_BIOS.22_error| entsprechende KVM-Wiki-Seite]. Jede andere Fehlermeldung deutet wahrscheinlich auf einen Fehler hin und sollte gemeldet werden.

Wenn das alles reibungslos funktioniert, sollten Sie sicherstellen, dass Ihre VMs tatsächlich KVM nutzen.

Verwendet mein Gastsystem KVM?

Oftmals sind sich Anwender unsicher, ob ihr QEMU-Gastsystem tatsächlich Hardware-Virtualisierung über KVM nutzt.

Prüfen Sie zunächst, ob libvirt KVM als verfügbar erkennt:

<pre> $> virsh capabilities | grep kvm <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> </pre>

Falls dies keine Ergebnisse liefert, versuchen Sie diesen Befehl, um weiter zu ermitteln, was möglicherweise behoben werden muss, um die KVM-Unterstützung zu aktivieren:

<pre> $> virt-host-validate </pre>

Überprüfen Sie als Nächstes, ob das Gastsystem für die Verwendung von KVM konfiguriert ist:

<pre> $> virsh dumpxml ${guest} | grep kvm <domain type='kvm' id='18'> <emulator>/usr/bin/qemu-kvm</emulator> </pre>

Falls dies keine Ergebnisse liefert, müssen Sie <domain type='kvm'> und <emulator>/usr/bin/qemu-kvm</emulator> mit folgendem Befehl erstellen:

<pre> virsh edit ${guest} </pre>

Überprüfen Sie als Nächstes die Datei <code>/var/log/libvirt/qemu/${guest}.log</code>, um sicherzustellen, dass <code>/usr/bin/qemu-kvm</code> der von libvirt ausgeführte Emulator ist und keine Fehlermeldungen bezüglich <code>/dev/kvm</code> vorliegen.

Wenn Sie es richtig ausgefallen mögen, können Sie überprüfen, ob <code>qemu-kvm</code> die Datei <code>/dev/kvm</code> geöffnet hat:

<pre> $> for iii in /proc/$(ps h -o tid -C qemu-kvm)/fd/*; do readlink $iii; done | grep kvm anon_inode:kvm-vcpu /dev/kvm anon_inode:kvm-vm </pre>

Zugriff auf die serielle Konsole zur Fehlerbehebung und Verwaltung

Der Zugriff auf die serielle Konsole ist nützlich zum Debuggen von Kernel-Abstürzen, und die Fernverwaltung kann sehr hilfreich sein.

Bei einem vollständig virtualisierten Gast-Betriebssystem wird automatisch eine serielle Konsole konfiguriert; der Gast-Kernel ist jedoch standardmäßig nicht für deren Nutzung eingerichtet. Um die Gast-Konsole bei einem vollständig virtualisierten Linux-Gast zu aktivieren, bearbeiten Sie die Datei /etc/grub.conf im Gastsystem und fügen Sie console=tty0 console=ttyS0 hinzu. Dadurch wird sichergestellt, dass alle Kernel-Meldungen sowohl an die serielle Konsole als auch an die reguläre grafische Konsole ausgegeben werden. Auf die serielle Konsole kann anschließend auf die gleiche Weise wie bei paravirtualisierten Gästen zugegriffen werden:

<pre> su -c "virsh console <Domainname>" </pre>

Alternativ lässt sich die serielle Konsole auch über das grafische Programm <code>virt-manager</code> anzeigen. Öffnen Sie dazu einfach das Fenster „Konsole“ oder „Details“ für den Gast und wählen Sie in der Menüleiste „Ansicht“ → „Serielle Konsole“ aus. Möglicherweise muss <code>virt-manager</code> mit Root-Rechten ausgeführt werden, um über die erforderlichen Berechtigungen für den Zugriff auf die serielle Konsole zu verfügen.

Zugriff auf die grafische Konsole

Um eine grafische Konsole für Ihr Gastsystem zu erhalten, können Sie entweder „virt-manager“ verwenden und das Konsolensymbol für den Gast auswählen, oder Sie nutzen das Werkzeug „virt-viewer“, um sich direkt mit der Konsole zu verbinden:

<pre> virt-viewer Gastsystemname </pre>

Zugriff auf Daten in Gast-Disk-Abbildern

{{Admon/caution | Wenn das Gast-Abbild möglicherweise gerade aktiv genutzt wird, dürfen Sie nur lesend darauf zugreifen; andernfalls riskieren Sie eine Beschädigung des Disk-Abbilds.<br><br>Die Verwendung von <code>guestfish --ro</code> ist immer sicher.}}

Mit dem Programm [http://libguestfs.org/guestfish.1.html guestfish] können Sie Festplatten-Abbilder von Gastsystemen bearbeiten, ohne den Gast ausführen zu müssen:

<pre> su -c 'yum install guestfish' guestfish -d NameOfGuest -i --ro ><fs> ll / ><fs> cat /boot/grub/grub.conf </pre>

Informationen und Beispiele finden Sie unter <code>man guestfish</code> sowie auf [http://libguestfs.org/ der libguestfs-Website]. guestfish lässt sich auch per Skript steuern.

[http://libguestfs.org/virt-rescue.1.html virt-rescue] ist ein alternatives libguestfs-Werkzeug, mit dem Sie Ad-hoc-Änderungen vornehmen können. [http://libguestfs.org/virt-edit.1.html virt-edit] lässt sich zum Bearbeiten einzelner Dateien in Gastsystemen verwenden, z. B.:

<pre> virt-edit Gastsystemname /boot/grub/grub.conf </pre>

Bekannte Probleme

Audio-Ausgabe

Die Einrichtung der Audioausgabe unter libvirt war schon immer schwierig, doch die jüngsten Sicherheitsänderungen haben tatsächlich die nötigen Mechanismen bereitgestellt, um dies zu ermöglichen. Das Hauptproblem besteht darin, dass die VM die Audioausgabe nicht an die PulseAudio-Sitzung Ihres Benutzers sendet. Es gibt zwar möglicherweise eine PulseAudio-Option, um dieses Problem zu umgehen, aber ich habe es folgendermaßen zum Laufen gebracht:

  • [[SELinux/FAQ#How_do_I_enable_or_disable_SELinux_.3F|Setzen Sie SELinux auf permissiv]].

  • Konfigurieren Sie libvirt so, dass [[#Changing_the_QEMU.2FKVM_process_user|Gastsysteme unter Ihrem normalen Benutzerkonto ausgeführt werden]].

  • Setzen Sie <pre>vnc_allow_host_audio = 1</pre> in /etc/libvirt/qemu.conf und starten Sie libvirtd mit <pre>service libvirtd restart</pre> neu

Dieses Problem wird sich künftig direkt „out-of-the-box“ lösen lassen, indem der grafische VNC-Client Audiosignale von der VM empfängt und sie im Kontext des aktuellen Benutzers wiedergibt. Es existiert bereits Code zur Umsetzung dieser Funktion für virt-viewer/virt-manager, der jedoch noch nicht vollständig ausgereift ist. Weitere Informationen finden Sie unter [https://bugzilla.redhat.com/show_bug.cgi?id=595880 gtk-vnc-Bug 595880], [https://bugzilla.redhat.com/show_bug.cgi?id=536692 libvirt-SDL-Audio-Bug 536692] und [https://bugzilla.redhat.com/show_bug.cgi?id=508317 libvirt-VNC-Audio-Bug 508317].

SDL-Grafik

QEMU benötigt Zugriff auf Ihre $XAUTHORITY-Datei, um SDL-Grafik verwenden zu können.

  • Konfigurieren Sie die SDL-Grafik für Ihre VM. Am einfachsten geht das so:

<pre>$> echo <graphics type='sdl display='$DISPLAY' xauth='$XAUTHORITY'/> <graphics type='sdl display=':0.0' xauth='/home/cole/.Xauthority'/> (diese Zeichenkette kopieren) $> su -c 'virsh edit $vmname' (diese Zeichenkette irgendwo in den <devices>-Block einfügen, alle anderen <graphics>-Geräte entfernen) </pre>

  • [[SELinux/FAQ#How_do_I_enable_or_disable_SELinux_.3F|Setzen Sie SELinux auf „permissive“]]. Weitere Informationen finden Sie unter [https://bugzilla.redhat.com/show_bug.cgi?id=609279 Bug 609276].

  • Gewähren Sie dem VM-Benutzer Zugriff auf Ihre $XAUTHORITY-Datei. Der Standard-VM-Benutzer unter Fedora 12 und neuer ist qemu; Sie können daher Lesezugriff mit <pre>setfacl -m u:qemu:r $XAUTHORITY</pre> gewähren. Sollte dabei der Fehler „operation not supported“ (Operation nicht unterstützt) auftreten, können Sie alternativ einen weniger restriktiven Lesezugriff mittels <pre>chmod +r $XAUTHORITY</pre> einrichten. Beachten Sie jedoch, dass dies wahrscheinlich Sicherheitsrisiken birgt. Falls dies nicht funktioniert, können Sie den VM-Benutzer alternativ entweder auf root (das Verhalten älterer Fedora-Versionen) oder [[#Changing_the_QEMU.2FKVM_process_user|auf Ihren eigenen regulären Benutzer]] umstellen.

Fehler beim Verwenden von <interface type='ethernet'/>

Das Standardverhalten von Libvirt, die Capabilities des QEMU/KVM-Prozesses zu verwerfen, verhindert die korrekte Funktion von <interface type='ethernet'/>. Sie können Folgendes versuchen:

  • Veranlassen Sie libvirt dazu, [[#Changing_QEMU.2FKVM_process_capabilities|die Prozess-Capabilities von QEMU/KVM nicht aufzugeben]].

Sollte das nicht ausreichen, könnten Sie Folgendes versuchen:

  • [[SELinux/FAQ#How_do_I_enable_or_disable_SELinux_.3F|SELinux auf „permissive“ setzen]]

  • Lassen Sie libvirt [[#Changing_the_QEMU.2FKVM_process_user|QEMU/KVM als root ausführen]]

PCI-Gerätezuordnung

Das Standardverhalten von Libvirt, bestimmte Prozess-Capabilities von QEMU/KVM zu verwerfen, verhindert die korrekte Zuweisung von PCI-Geräten. Weitere Informationen finden Sie unter [https://bugzilla.redhat.com/show_bug.cgi?id=573850 Bug 573850]. Ich konnte dies nur mit den folgenden Schritten zum Laufen bringen:

  • Veranlassen Sie libvirt dazu, [[#Changing_QEMU.2FKVM_process_capabilities|die Prozess-Capabilities von QEMU/KVM nicht aufzugeben]].

  • [[SELinux/FAQ#How_do_I_enable_or_disable_SELinux_.3F|SELinux auf „permissive“ setzen]]

  • Lassen Sie libvirt [[#Changing_the_QEMU.2FKVM_process_user|QEMU/KVM als root ausführen]]

Want to help? Learn how to contribute to Fedora Docs ›