Umstellung auf virt-manager

Hintergrund

Seit ich in die Welt von Linux eingestiegen bin, ist mir klar geworden, dass es diese gibt
verschiedene „Kaninchenlöcher“ (wie ich es gerne nenne), in die ich mich hineinversetzen konnte. ich
Definieren Sie diese „Kaninchenlöcher“ als den Zeitraum, in dem Sie Ihre Zeit mit der Adoption verbringen
eine bestimmte Technologie in Ihren Workflow. Die meisten dieser Workflows sind manchmal
sehr ungewöhnlich. Einer meiner ersten „Kaninchenlöcher“ war zum Beispiel der Wechsel zu a
Kachelfenstermanager. Es gibt bereits keinen großen Prozentsatz von Menschen, die es verwenden
Linux auf ihren Desktops, ganz zu schweigen von einem Kachelfenster-Manager-Setup. Einer von
die „Kaninchenlöcher“, in die ich kürzlich geraten bin – daher der Titel
Artikel – wechselt von VirtualBox zu virt-manager. hatte ich schon gesehen
Es gibt bereits viele Videos und Artikel über dieses QEMU/KVM-Ding. So war es
vorhersehbar, dass ich das irgendwann abholen werde.

Einführung

In einem früheren Blog haben wir Gnome-Boxen behandelt. Es gibt jedoch
auch ein anderer Manager für virtuelle Maschinen, der sehr beliebt ist
Virt-Manager. Obwohl es sehr einfach zu bedienen ist, habe ich festgestellt, dass gnome-boxes
bietet uns nicht viele Konfigurationen im Vergleich zu virt-manager .
Außerdem virt-manager bietet auch eine bessere Leistung als
im Vergleich zu VirtualBox, da wir KVM verwenden. In diesem Artikel wünsche ich
einige meiner Erfahrungen zu teilen und was ich daraus gelernt habe
Kaninchenbau.

Bevor wir jedoch darauf eingehen, möchte ich ein paar Dinge klarstellen:

• Hypervisor :Ein Hypervisor ist eine Software, die es uns ermöglicht, und auszuführen
  Verwalten Sie mehrere verschiedene Betriebssysteme auf einer einzigen Maschine. Typ 1
  Hypervisor werden direkt auf der Hardware ausgeführt, während die Typ-2-Hypervisoren weiterlaufen
  top eines auf der Hardware installierten Betriebssystems.
• KVM – Dies ist das Low-Level-Kernelmodul, das für die Übersetzung verantwortlich ist
  die CPU-Anweisungen von Gastbetriebssystemen in etwas, das der Host
  Kernel verstehen kann. Dies ist im Grunde das, was dem Linux-Kernel erlaubt zu handeln
  als (Typ 1) Hypervisor[1].
• QEMU – QEMU steht für Quick-Emulator. Es emuliert verschiedene Hardware und CPU
  Architekturen. QEMU kann arbeitet mit KVM, kann aber auch alleine verwendet werden
  [2]. Dies führt jedoch zu verschiedenen Leistungsproblemen, wenn die Emulation durchgeführt wird
  vollständig über Software. Nun, KVM selbst kann auch nicht viel emulieren
  Hardware. Daher wird der QEMU+KVM-Stack am häufigsten als Hypervisor verwendet.
• libvirt – libvirt ist eine API, die verwendet werden kann, um virtuelle Maschinen über QEMU zu verwalten.
  Es hat einen Daemon namens libvirtd und ein Befehlszeilendienstprogramm namens virsh [3].
  Allerdings habe ich mich noch nicht mit virsh beschäftigt das ist also ein weiteres Kaninchenloch für mich.
• virt-manager – Schließlich ist dies das GUI-Programm zum Verwalten virtueller Maschinen. Es benutzt
  libvirt für die Interaktion mit den untergeordneten Komponenten unseres Virtualisierungsstapels.
  Wir werden in erster Linie als Benutzer damit interagieren.
  

virt-manager installieren

Normalerweise sollte der Versuch, virt-manager zu installieren, automatisch libvirt-Komponenten als einlesen
Abhängigkeiten. Allerdings qemu ist eine optionale Abhängigkeit, daher müssen wir sie explizit angeben.
Unter Arch Linux brauchte ich nur diese beiden Pakete:

Bitte stellen Sie sicher, dass die erforderlichen Pakete im obigen Screenshot angezeigt werden
werden während der Installation auf Ihrem System eingezogen.

Virt-Manager verwenden

virt-manager ist ein GUI-Programm. Daher sollte die Benutzeroberfläche nicht wirklich viel Erklärung erfordern.

Zu beachten ist, dass Sie die libvirtd haben müssen Dienst läuft, um virt-manager zu verwenden.

# systemctl start libvirtd

Eine kleine Anmerkung, das Starten von libvirt startet auch ein paar andere Dienste, also führe ich Folgendes aus
Befehl, wenn ich mit der Verwendung meiner VMs fertig bin:

# systemctl stop "libvirt*" "virt*"

Virtuelle Laufwerke

virt-manager verwendet denqcow2 Speicherformat für seine virtuellen Laufwerke. Seit dem
Artikel über die Migration zum Virt-Manager handelt, haben wir wahrscheinlich einige virtuelle
Maschinen mit bestückten Festplatten. Glücklicherweise haben wir das qemu-img Dienstprogramm.

Zum Beispiel, um ein Bild von vdi zu konvertieren Format zu qcow2 :

qemu-img convert -O qcow2 -f vdi <image.vdi> <output_file.qcow2>

Es werden auch andere Formate unterstützt, die durch Aufrufen angezeigt werden können:

qemu-img --help

VirtualBox-Images gibt es auch in ova Format. Und Sie werden dieses Format nicht finden
in der Hilfeausgabe des vorherigen Befehls aufgeführt.
Allerdings bei der Untersuchung einer ova Datei:

Es handelt sich offensichtlich nur um ein tar-Archiv – das sich einfach mit tar entpacken lässt :

Dort haben wir unser vmdk virtuelle Festplatte, die einfach in qcow2 konvertiert werden kann .

SSH in VMs

Immer wenn ich eine virtuelle Maschine in VirtualBox erstellt habe, habe ich sie so konfiguriert, dass sie überbrückt ist
Adapter. Auf diese Weise wäre die VM auch in meinem Heim-LAN und ich könnte wie jede andere per SSH darauf zugreifen
andere Maschine. Standardmäßig werden die VMs in virt-manager jedoch mit dem verbunden
Virtuelles Netzwerk (NAT). Die IPs werden intern von dem Hypervisor vergeben, den Sie verwenden
Heimrouter wird nichts wissen. Wenn Sie also versuchen, ssh zu senden in die VM mit dieser IP,
Das Gateway hat keine Ahnung, was diese IP ist, und daher funktioniert es nicht.

Die Art und Weise, wie ich den Router dazu bringen konnte, meiner virtuellen Maschine auch eine IP zuzuweisen
indem Sie zuerst eine Netzwerkbrücke erstellen und dann die Netzwerkkonfiguration der bearbeiten
VM, wie im Screenshot gezeigt, von der Bridge-Quelle sein und wenn die VM hochfährt
es erhält eine IP, auf die andere Geräte im LAN zugreifen können.

Das Einrichten einer Netzwerkbrücke ist auf Seiten wie Arch Wiki [4] gut dokumentiert.
Ich verwende Network Manager und das Verfahren war so einfach wie die Eingabe einiger weniger
Befehle. Der Brückenname ist br0 und die diesem als Slave zugeordnete Schnittstelle
Brücke ist eth0 .

nmcli connection add type bridge ifname br0 stp no
nmcli connection add type bridge-slave ifname eth0 master br0
nmcli connection down eth0
nmcli connection up bridge-br0

Auf diese Weise kann ich einfach Sachen von und zur VM kopieren und einfügen, und ich habe auch keine
ständig der Tastatur/Maus zu entkommen, wenn Sie die VM und meinen Host verwenden
gleichzeitig.

Nachdem ich das alles herausgefunden hatte, konnte ich endlich virt-manager als meine primäre verwenden
Manager für virtuelle Maschinen. Das war's fürs Erste. Ich hoffe, Sie fanden diesen Artikel hilfreich.

Referenzen

1. Kernel-basierte virtuelle Maschine
2. KVM vs. QEMU
3. Libvirt-FAQ
4. Netzwerkbrücke | Arch-Wiki