• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Installation der KVM-tools unter openSUSE Leap 15.5

OP
Sendbote

Sendbote

Member
Welche sind es, sind alle in Post 19 aufgelisteten installierten Pakete aus dem Virtualisierungsrepo, weil sie als Systempakete angezeigt werden? Sollte ich diese entfernen bzw. durch die entsprechenden ersetzen?

Mittlerweile ist es mir gelungen, eine statische IP-Adresse auf einer KVM-Maschine mit Ubuntu Server 22.04 LTS einzurichten. Nach Eintrag einer neuen IP-Adresse neben der MAC-Adresse im Default-Netzwerk wie hier beschrieben, habe ich noch folgende Befehle ausgeführt:

Code:
# virsh net-destroy default
# virsh net-start default

Soweit ich mich erinnern kann, lief es im vergangenen Jahr ohne die letztgenannten Befehle, bereits mit "virsh net-update ...". Wie dem auch sei, offenbar gelingt es nun, aufgrund der Installation der KVM-tools virtuelle Maschinen zu verwalten.
 
OP
Sendbote

Sendbote

Member
Mir ist die Vorgehensweise nicht klar bzw. was die Folgen sind.

In Yast unter Software installieren / Anzeigen / Repositories / @'System finde ich viele Pakete. So benutze ich von hier den Chromium Webbrowser oder emacs 29.1. Im Hauptrepository dagegen finde ich nur 27.2 als höchste Version von emacs.

Würde das Umstellen in diesem Yast-Menü bedeuten: sowohl Haupt-Repository als auch Hauptaktualisierungs-Repository zu wählen und oben jeweils den blauen Link anzuklicken:
"Systempakete auf die Versionen in diesem Repository (Haupt-Repository) umstellen."
"Systempakete auf die Versionen in diesem Repository (Hauptaktualisierungs-Repository) umstellen." ?

Würde dies zu einer Zurückstufung einiger Programme, etwa von emacs, und möglicherweise auch zu Instabilitäten führen?
 

Sauerland

Ultimate Guru
Nimm die Liste aus Beitrag #19, gehe in Yast und suche nach jedem Pakete, markiere es dann und stell über den Reiter Versionen das Paket auf eine Version aus dem OSS Repo, Update Repo, Update SLE Repo oder Update Backports Repo um.

So stellst du nur die Pakete um, die du willst.


Wobei deine Probleme von deiner Repoliste herrühren.
 
OP
Sendbote

Sendbote

Member
Danke für Konkretisierung. An diesem Wochenende werde ich wahrscheinlich nicht mehr zu der Umstellung kommen. Ich melde mich spätestens Anfang nächster Woche wieder.
 
OP
Sendbote

Sendbote

Member
Bei vielen der Pakete aus Beitrag 19 kann ich derzeit nicht beurteilen, ob ich sie in der in Beitrag 24 beschriebenen Weise umstellen sollte. "brscanads2200ads2700w" gehört z.B. nicht dazu, weil es ein externes Paket eines Brother Scanners ist. Die Pakete von Virtualbox aus Beitrag 19 habe ich in der beschriebenen Weise umgestellt. Daneben gibt es noch andere Pakete aus Beitrag 19, die zum nun deaktivierten
Virtualsierungsrepo gehören, wie nach der vorübergehenden Aktivierung des Repos der Befehl

Code:
zypper se -sir Virtualisierung

zeigt.

Inwiefern besteht bei diesen, also bei den noch nicht umgestellten Paketen Handlungsbedarf? Würden die Pakete nicht auch bei ihrer nächsten Aktualisierung umgestellt werden?

Mich würde nun noch die Bedeutung des Ausdrucks interessieren:

Code:
zypper se -si | grep -Ei 'system_p|system p|system-p|systemp'


Ich würde ihn so übersetzen:
Zeige die Zeilen, die
- Details (etwa Versionsnummern) aller installierten Versionen der Pakete enthalten und in denen
- unabhängig von Klein- oder Großschreibung
- der String "system_p" oder "system p" oder "systemp" vorkommt.

Mit

Code:
zypper se -si | grep Systempakete

komme ich zu demselben Ergebnis.
Wahrscheinlich ist obiger Befehl eine Art Universalausdruck für verschieden Sprachen.
 

Sauerland

Ultimate Guru
Inwiefern besteht bei diesen, also bei den noch nicht umgestellten Paketen Handlungsbedarf? Würden die Pakete nicht auch bei ihrer nächsten Aktualisierung umgestellt werden?
Nein, zypper up macht keinen Repowechsel, daher sollst du das machen.........
Wahrscheinlich ist obiger Befehl eine Art Universalausdruck für verschieden Sprachen
Ja, hast du genau analisiert
 
Zuletzt bearbeitet:
OP
Sendbote

Sendbote

Member
Nein, zypper up macht keinen Repowechsel, daher sollst du das machen.........

Wann macht Zypper den Repowechsel? Manchmal scheint er zu erfolgen:

Installing or removing software
If the resulting package has a higher version number than the installed one, the installed package will be updated and replaced with the selected update candidate.

This option tries to avoid changes in architecture and vendor for the installed packages, but under certain circumstances, they are tolerated.
 

Sauerland

Ultimate Guru
Wann macht Zypper den Repowechsel? Manchmal scheint er zu erfolgen:
Nein.......
Nur wenn du aus einem 3-Repo ein Paket installiert hast, dieses Paket bei einem Update als Abhängigkeit einen neuere lib benötigt als bereits installiert ist, wird diese lib aus dem 3-Repo installiert und die andere deinstalliert.

Und du musst dem immer noch als User zustimmen............

Daher bei jedem Update:
lesen, lesen , lesen.......
 
OP
Sendbote

Sendbote

Member
Mittlerweile habe ich die meisten der in Beitrag 19 erscheinenden Pakete mit Yast auf das OSS Repository umgestellt, wozu auch die Pakete von Virtualbox gehören.

Code:
$:~> zypper se -si | grep Systempakete
i+ | brscanads2200ads2700w                       | Paket   | 0.1.15-1                                         | x86_64 | (Systempakete)
i  | openSUSE-release-dvd                        | Paket   | 15.5-lp155.286.1                                 | x86_64 | (Systempakete)

KVM-Maschinen kann ich nun starten. Doch es ist dann nicht möglich, zur gleichen Zeit auch virtuelle Maschinen in Virtualbox zu nutzen. Dies ging unter Opensuse 15.4 mit Paketen aus den gleichen Repositories, die ich in Beitrag 2 zeigte. "Intel Virtualization Technology" ist in den UEFI-Einstellungen ermöglicht.

Wenn eine KVM-Maschine läuft und man bei Virtualbox eine virtuelle Maschine starten will, erscheint folgende Meldung:

Code:
VirtualBox can't operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).

Result Code:  NS_ERROR_FAILURE (0X80004005)
Component:  ConsoleWrap

Interface:  IConsole {6ac83d89-6ee7-4e33-8ae6-b257b2e81be8}


Hier habe ich einen älteren Beitrag aus dem Jahr 2010 gefunden.
Damals lautete der Vorschlag:

Code:
root@localhost:~# lsmod |grep kvm

kvm_intel              32832  0
kvm                   182683  1 kvm_intel

root@localhost:~# modprobe -r kvm_intel

Bei mir ergibt

Code:
localhost: #       lsmod |grep kvm
kvm_intel             335872  0
kvm                  1056768  1 kvm_intel
irqbypass              16384  1 kvm

Würde hier auch dieser Befehl weiterhelfen,
also das Entfernen des Moduls kvm_intel aus dem Kernel?

Code:
modprobe -r kvm_intel

Oder gibt es geignetere / aktuellere Wege, dass ich wieder gleichzeitig auf KVM-Maschinen und Virtualbox-Maschinen zugreifen kann?
 

susejunky

Moderator
Teammitglied
Hallo @Sendbote ,

zu Deinem eigentlichen Thema kann ich nichts beitragen, aber hier ein Hinweis:

Würde hier auch dieser Befehl weiterhelfen,
also das Entfernen des Moduls kvm_intel aus dem Kernel?

Code:
modprobe -r kvm_intel

modprobe -r MODUL löscht das Kernelmodul nicht, sondern entlädt es lediglich aus dem Hauptspeicher; d.h. Du kannst einfach ausprobieren, ob das Entladen Dein Problem löst (das Kernel-Modul "geht dabei nicht verloren").

Allerdings lassen sich Kernel-Module nur dann entladen, wenn sie nicht aktiv verwendet werden.

Sollte das Modul genutzt werden, kannst Du versuchen mittels "blacklisting" zu verhindern, dass das Modul beim Systemstart geladen wird.

Viele Grüße

susejunky
 
OP
Sendbote

Sendbote

Member
Danke für die Hinweise, @susejunky.

Das KVM-Modul (kvm-intel) konnte ich mit dem Befehl aus Beitrag 30 deaktivieren. Damit hat es offenbar kein anderer Prozess verwendet. Nach einem Reboot trat allerdings wieder das in Beitrag 30 beschriebene Problem auf.

Mit dem Entladen aus dem Hauptspeicher und einem Reboot ist es nicht getan, wie auch die Meldung aus Beitrag 30 sagt:

Code:
VirtualBox can't operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).

Result Code:  NS_ERROR_FAILURE (0X80004005)
Component:  ConsoleWrap

Interface:  IConsole {6ac83d89-6ee7-4e33-8ae6-b257b2e81be8}

Aber wie soll ich den Kernel rekompilieren? Auch nach einiger Recherche habe ich keine Ahnung, wie ich das machen soll.

Der Befehl entlädt das Moduls also nur für die derzeitige Sitzung. Später habe ich deswegen erneut den obigen Befehl ausgeführt, leider als die Virtuelle-Maschinenverwaltung gerade lief und erhielt dann als Antwort:

Code:
# modprobe -r kvm_intel
modprobe: FATAL: Module kvm_intel is in use.

Ich hoffe, damit nichts kaputt gemacht zu haben.

Code:
modprobe kvm_intel

hat das Modul offenbar wieder geladen und ich konnte die Virtuelle-Maschinenverwaltung wieder starten.
 

Sauerland

Ultimate Guru
Die zwei Virtualisierungen benutzen beide die Hardware Virtualisierung, aber die gleichzeitige Benutzung ist nicht vorgesehen.


Wobei sich mir nicht erschließt, warum 2 Virtualisierungslösungen benutzt werden.......
 
OP
Sendbote

Sendbote

Member
Wobei sich mir nicht erschließt, warum 2 Virtualisierungslösungen benutzt werden.......
Ich möchte mich in die Virtuelle-Maschinenverwaltung (KVM) einarbeiten, habe den Eindruck, dass diese grundsätzlich stabiler und umfassender als Virtualbox ist unter Linux. Doch die Lernkurve verläuft dort steiler als bei Virtualbox, so ist mein Eindruck. Es hat funktioniert, dass ich die beiden Virtualisierungsmöglichkeiten parallel nutzte und ich vermute, dass dies auch jetzt möglich ist. Ich habe verschiedene virtuelle Maschinen in Virtualbox, die ich derzeit nicht alle in die Virtuelle-Maschinenverwaltung (KVM) importieren möchte, habe quasi Virtualbox immer noch als Ausweichmöglichkeit.
 

josef-wien

Ultimate Guru
Ich hoffe, damit nichts kaputt gemacht zu haben
Die Hoffnung entspricht der Realität.

Aber wie soll ich den Kernel rekompilieren?
Dazu sehe ich keinen Grund, da das Entladen ja ausreichend ist. Und es wäre kontraproduktiv, wenn Du kvm verwenden willst.

Eine blacklist-Eintragung in einem der Verzeichnisse laut man modprobe.d könnte nur das automatische Laden beim Systemstart verhindern, um das manuelle Entladen und Laden kommst Du nicht herum.

P. S. modprobe -r kvm_intel entlädt kvm_intel und kvm, modprobe kvm_intel lädt kvm und kvm_intel.
 
OP
Sendbote

Sendbote

Member
Das Entladen ist ausreichend für das Arbeiten mit Virtualbox.

Ja, es ist kontraproduktiv für KVM bzw. es verhindert das Starten einer KVM in der Virtuellen-Maschinenverwaltung:

Code:
Fehler beim Starten der Domain: Nicht unterstützte Konfiguration: Domain verlangt KVM, aber es ist nicht verfügbar. Überprüfen Sie, dass die Virtualisierung im Host-BIOS aktiviert ist, und die Host-Konfiguration eingerichtet ist die KVM-Module zu laden.

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1425, in startup
    self._backend.create()
  File "/usr/lib64/python3.6/site-packages/libvirt.py", line 1373, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: Nicht unterstützte Konfiguration: Domain verlangt KVM, aber es ist nicht verfügbar. Überprüfen Sie, dass die Virtualisierung im Host-BIOS aktiviert ist, und die Host-Konfiguration eingerichtet ist die KVM-Module zu laden.

Erst nach
Code:
systemctl start libvirtd
virsh net-start default
modprobe kvm_intel

kann ich wieder eine KVM in der Virtuellen-Maschinenverwaltung starten.
 
Oben