Virtuelle Maschine - welches Programm?

[ben.a]

Ich möchte auf meinem Debian-Host eine virtuelle Maschine benutzen, in der ebenfalls Debian (mit Gnome) laufen soll - z.B. um dort Zoom und andere proprietäre Software zu isolieren. In älteren Versionen von Debian hätte ich hierfür Virtualbox installiert. Dies ist aber nicht mehr in den Debian-Repos, und nicht freie Software (https://wiki.debian.org/VirtualBox). Das Debian-Wiki (https://wiki.debian.org/SystemVirtualization) nennt zahlreiche Alternativen: Qemu, KVM, lib-virt. Die Beziehungen zwischen den unterschiedlichen Programmen ist mir nicht klar: ist lib-virt ein Frontend, um virtuelle Maschinen zu verwalten?
Kurz: ich suche den einfachsten Weg, ein Debian mit Gnome in einer VM unter Debian zu installieren - könnt ihr mir sagen, was ich installieren sollte? Gibt es ein Tutorial dafür?

[rhHeini]

Da Du VBox kennst: Du kannst VBox direkt von Oracle herunterladen und mit dpkg -i installieren. Funzt wie gehabt.

rolf

[inne]

Der virt-manager ist nicht viel komplizierter, wenn man sich etwas rein-kniet. Mich stört da nur das sich virt-manager in die iptables Regeln einklinkt, was VirtualBox nicht macht und was dort anders/schöner gelöst sein muss. Da wollte ich eh auch noch mal was fragen hier.

[debianuser4782]

Die Kernel-based Virtual Machine (KVM; deutsch „Betriebssystem-Kern-basierte virtuelle Maschine“) ist eine Infrastruktur des Linux-Kernels zur Virtualisierung, die auf mit den Hardware-Virtualisierungstechniken von Intel (VT) oder AMD (AMD-V) ausgestatteten x86-Prozessoren sowie auf der System-z-Architektur lauffähig ist.
...
KVM selbst nimmt keine Emulation vor, sondern stellt nur die Infrastruktur dazu bereit; QEMU ist derzeit die einzige Möglichkeit, diese zu nutzen. Dazu stellt QEMU für virtualisierte Gastsysteme die notwendigen Geräte wie Festplatten, Netzwerk-, Sound- und Grafikkarten zur Verfügung. ... [1]

libvirt ist eine Sammlung quelloffener Werkzeuge zur Verwaltung von virtuellen Maschinen auf einem Hostsystem. Diese besteht aus einer Programmierschnittstelle (API), einem Daemon (libvirtd) und einem Kommandozeilenprogramm (virsh). Mit Hilfe von libvirt ist es möglich, Hypervisortechnologien unterschiedlicher Hersteller wie beispielsweise KVM/QEMU, Xen, VMware, VirtualBox oder Hyper-V zu steuern und über eine einheitliche Schnittstelle zu bedienen. ... [2]

Virtual Machine Manager (Paketname virt-manager) ist eine freie graphische Benutzeroberfläche zum Verwalten von Hypervisoren wie KVM, Xen oder QEMU. Das Programm basiert auf der Bibliothek libvirt und wird von Red Hat entwickelt. ... [3]

KVM ist also bereits im Linux-Kernel einer normalen Debian-Installation per default implementiert.
Qemu ist die bisher einzige Möglichkeit diese Kerneltechnik zu nutzen, um die gewünschte Hardware zu emulieren.
Virsh ist ein VM-Verwaltungswerkzeug aus aus der Werkzeugsammlung libvirt als Frontend für das CLI.
Mit Virsh kommt man nur in Berührung, wenn man nicht ausschließlich alles über Virt-Manager als "GUI-Frontend" verwalten möchte.
Die Begriffe API und Deamon müsste jemand anderes erklären.

[1] https://de.wikipedia.org/wiki/Kernel-ba ... al_Machine
[2] https://de.wikipedia.org/wiki/Libvirt
[3] https://de.wikipedia.org/wiki/Virtual_Machine_Manager

Tutorials:
https://wiki.debian.org/KVM
https://www.whonix.org/wiki/KVM

Mit virt-manager:

Code: Alles auswählen

# apt install qemu-kvm libvirt-clients libvirt-daemon-system virt-manager 

oder minimal mit Virsh + virt-viewer (Es muss hier alles über Terminal [CLI] verwaltet werden. Um nicht gleich mit virsh überfordert zu werden, kann man auch zunächst alle VMs mit der obigen maximalen Installation einrichten, danach alle obigen Pakete purgen und die folgende Minimalinstallaltion ausführen. Die eingerichteten VMs bleiben durch das Purgen der Pakete nämlich unberührt.)

Code: Alles auswählen

# apt install qemu-kvm libvirt-clients libvirt-daemon-system virt-viewer dnsmasq --no-install-recommends --no-install-suggests

Danach in beiden Fällen:

Code: Alles auswählen

# adduser [youruser] libvirt 

und

Code: Alles auswählen

# adduser [youruser] livirt-qemu

sowie

Code: Alles auswählen

# virsh -c qemu:///system net-autostart default

Code: Alles auswählen

# virsh -c qemu:///system net-start default

danach am besten

Code: Alles auswählen

# reboot

In der Gast-VM mit debian-Gnome dann ggf

Code: Alles auswählen

# apt install spice-vdagent

damit sich die Anzeige der VM auf die Bildschirmgröße maximieren lässt.

[Tintom]

Danke für die Erläuterung!

[TomL]

Mich stört da nur das sich virt-manager in die iptables Regeln einklinkt, was VirtualBox nicht macht und was dort anders/schöner gelöst sein muss.

Es ist 'anders' gelöst... ob das besser ist, weiß ich noch nicht. VB verwendet in seinem Virtualisierungssystem einen virtuellen Router, der DHCP und Masquerading macht. Das funktioniert, soweit ich das verstanden habe, weil das eine Vollvirtualisierung ist, ähnlich wie Qemu. Dem entgegen ist KVM keine Vollvirtualisierung, setzt stattdessen im Kernel direkt auf der Hardware auf und nutzt nur die Qemu-Infrastruktur für Devices, etc. KVM nutzt deshalb für den gleichen Zweck statt eines Routers der Einfachheit halber fürs masquerading den Paketfilter. Den dhcp-Server übernimmt einfach dnsmasq als Daemon. Ich halte das für transparenter und infolgedessen nach meinen Ansprüchen auch für besser.

Wobei ich Deine Meinung mit den Paketfilter-Regeln nachvollziehen kann... das ist auch für mich ein NoGo, dass ein Tool Veränderungen an meinem Paketfilter vornimmt und Regeln einfügt, die ggf. an meinen Vorgaben vorbei eigene Entscheidungen treffen. Für mich ist das eine Prinzipfrage... und kompromisslos ausgeschlossen.

Es gibt dafür 2 Lösungen. Entweder man kreiiert ein eigenes virtuelles Netz mit NAT und integriert eigene passende Regeln in seinen bestehenden Filter. Eine solche Netzwerk-Infrastruktur startet man dann selber, z.B. via systemd-Service-Units, die wird nicht mehr vom Virt-Manager gestartet. Das funktioniert auf ETH und WLAN. Oder man richtet die VM als regulären LAN-Client ein, der direkt vom DSL-Router eine IP-Adresse und via RA auch einen IPv6-Prefix bezieht (wenns den gibt). Das funktioniert allerdings nur mit ETH. Mit Variante 1 läuft die VM in einem isolierten Netzwerk, mit Variante 2 wird die VM zum vollwertigen LAN-Client.

[inne]

@TomL

Danke für das Aufzeigen der zwei Lösungen. Ich habe mit virt-manager schon etwas probiert, nutze aber noch VirtualBox. Werde mal sehen ob mich das weiterbringt.

Das besser vermag ich eigentlich sowie so nicht allgemein beantworten. Es ist eher auf mein Setup bezogen, und da dann auch nur auf mein Wissens- und aktuellen Arbeitsstand. Denn meine iptables-Regel überhaupt dahingehend anpassen, das will ich eigentlich überhaupt nicht. Und meine VirtualBox VM haben mehrere Physische-Netze/Adapter in denen immer nur entsprechende Dienste erreichbar sind. So das z.B. nur der Host SSH und Datenbank etc. erreichen kann. Und vom Internet nur httpd usw.
Ob ich DHCP dort überhaupt brauche? Das muss ich noch sehen, eigentlich nicht.

[TomL]

Ob ich DHCP dort überhaupt brauche? Das muss ich noch sehen, eigentlich nicht.

Die VM braucht notwendigerweise Zugriff auf einen DHCP-Server... es sei denn, Du hättest eine Static-IP im NIC der VM eingerichtet. Das wäre aber eher nur üblich, wenn die VM als dedizierter Server mit irgendeinem besonderen Service für andere Clients im LAN laufen sollte.... bei mir ist das beispielsweise Pihole. Im Normalfall bekommt die VM via DHCP entweder eine IP des isolierten Netzes vom Host-PC oder eine des regulären LAN vom DSL-Router .... aber ohne DHCP gehts nur mit einer Static-IP in der VM.

Das Default-Setup sowohl von VM als auch von libvirt/KVM ist NAT... und da werkelt der Host-PC in der einen oder anderen Weise als DHCP-Server.

[inne]

Ich mag nicht alles offenlegen. Nur soviel: Ich habe dort eigentlich schon überall statische IPs und der erste Default Adapter mit NAT läuft eigentlich umsonst mit, denn Internet sollten die VMs nun auch so schon haben.
Ich muss nur noch mal nachsehen wie ich das DHCP in virt-manager abschalte, denn ich meine selbst wenn ich dort keine IP-Range für das Netz angebe wurde iptables Regeln angelegt, wenn man den Adapter startet. Aber das wollte ich eigentlich später erst Fragen und weiter einrichten.

[TomL]

Ich mag nicht alles offenlegen. Nur soviel: Ich habe dort eigentlich schon überall statische IPs und der erste Default Adapter mit NAT läuft eigentlich umsonst mit, denn Internet sollten die VMs nun auch so schon haben.

NAT hat nichts mit DHCP oder Static-IP zu tun. Mit NAT werden IP-Pakete des isolierten VM-Netzes LAN-Tauglich gemacht. Es sei denn, die Static-IPs sind nicht aus dem isolierten Netzwerk, sondern reguläre IPs des LANs (...vom DSL-Router). Ich weiss auch gar nicht, was "der erste Default-Adapter" ist..... es gibt auf dem Host das physische Device, ein Bridge-Device und virtuelle Devices für die VMs. Soweit ich mich erinnere, ist das bei VB und libvirt/KVM gleich gelöst.

Ich muss nur noch mal nachsehen wie ich das DHCP in virt-manager abschalte,...

Das ist unnötig. DHCP schaltet man ganz einfach in der VM selber ab.... und zwar in der Form, dass dort der DHCP-Client nicht verwendet wird. Dann bekommt die VM auch keine zugewiesene IP-Adresse. Das habe aber keine Auswirkung auf den Paket-Filter des Hosts, weil es eben NAT ist, muss der das Masquerading durchführen, also brauchts die Iptables-Regeln.

[inne]

Ich bezog mich damit auf diesen Text von dir.

Das Default-Setup sowohl von VM als auch von libvirt/KVM ist NAT... und da werkelt der Host-PC in der einen oder anderen Weise als DHCP-Server.

Aber Du hast recht, NAT selbst hat nichts mit DHCP zu tun.
Ich wollte nur klar machen, das hier bei mir die Default-Adaper in VirtualBox noch aktiv sind und nur diese noch via DHCP ihre IP bekommen.

[debianuser4782]

Nachtrag:

Im Falle der Benutzung von virt-viewer müsste virt-viewer separat von virsh in einer user-shell benutzt werden.

Die grafische Ansicht der laufenden VM öffnet man dann mit dem Befehl:

Code: Alles auswählen

$ virt-viewer -c qemu:///system [Name der VM] 

---------------------------------------------------------------------------

Eine Frage zu einem anderen Sachverhalt:

Nach folgenden Tutorials zur Einrichtung von qemu-kvm werden jeweils unterschiedliche Angaben zur Hinzufügung des Users zu den bei qemu-kvm relevanten Gruppen gemacht.

Im Tutorial https://wiki.debian.org/KVM, reicht ein

Code: Alles auswählen

# adduser <youruser> libvirt

Im Tutorial https://www.whonix.org/wiki/KVM wird

Code: Alles auswählen

sudo addgroup "$(whoami)" libvirt

Code: Alles auswählen

sudo addgroup "$(whoami)" kvm

angegeben.

Die von mir weiter oben im Thread geamachten Angaben, die sich auf ein früheres Tutorial bei whonix.org beziehen, und welche ich auch nach wie or in meinen Notizen niedergeschrieben habe, lauten:

Code: Alles auswählen

# adduser [youruser] libvirt 

Code: Alles auswählen

# adduser [youruser] livirt-qemu

Die letzte Variante benutze ich nach wie vor und sie funktioniert auch.

Welche Variante ist aber die solideste? Oder unterschieden sich die zwei ersten Tutorials nur hinischtlich ihrer Aktualität? Welche Variante wählt ihr?

[ben.a]

Vielen Dank an alle Beitragenden, das hat mir sehr geholfen. Die Anleitung von @debianuser4782 hat einwandfrei geklappt. Leider ist der Gast sehr langsam, ich muss noch etwas an den Einstellungen schrauben.

[debianuser4782]

Du kannst der VM ruhig alle CPU-Kerne geben. Das System kümmert sich dann um eine effiziente Verteilung der Threads zwischen Host und Gast. Für debian-Gnome sollten es zudem ungefähr 4 GB ram sein.