XEN vs. QEMU+KVM

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
fireburner
Beiträge: 111
Registriert: 01.12.2017 20:51:31
Lizenz eigener Beiträge: neue BSD Lizenz
Wohnort: der wilde Süden

XEN vs. QEMU+KVM

Beitrag von fireburner » 14.01.2018 17:40:57

Hallo zusammen,

auf meinem Server möchte ich verschiedene Services in eigenen VMs laufen lassen.
Als Host kommt Debian 9 zum Einsatz. Die VMs werden auf einem ZFS Pool gespeichert.

Allerdings schwanke ich zwischen XEN und QEMU+KVM als Hypervisor.
Je mehr ich lese, desto weniger kann ich mich entscheiden.
Hat wer Erfahrung mit einem der beiden Systeme?
Welches würdet ihr empfehlen?

Zum Managen und Aufsetzen der VMs dachte ich an virt-manager über ssh.
Weiß wer ob die Authentifizierung auch per ssh Key statt Passwort?
Zusätzliche komplexe Web-Oberflächen (Proxmox) wollte ich vermeiden.

Zugriff auf die VMs selbst würde ich, nach dem Aufsetzen und konfigurieren über den virt-manager, hauptsächlich per SSH machen.
Was wäre denn für VMs mt GUI zu empfehlen?
Auf einem Windows Guest kommt man vermutlich am besten über FreeRDP.

P.S. ich hatte bisher hauptsächlich VMs in Virtualbox auf meinem Desktop Rechner laufen. Hier fällt ja die Remote Verbindung zum Host weg und ich habe automatisch meine Fenster für jede VM egal ob CLI oder GUI.
Gewünscht ist hier ja ein headless Server der die VM Services laufen hat, die per SSH gemanged werden. Zusätzlich soll eben noch ein Windows Guest gehosted werden. Hier wäre dann eben vermutlich FreeRDP relevant. Zusätzlich werden wohl auch Linux VMs mit GUI aufgesetzt (für Spielereien), wo sich auch die Frage des Zugriffs auf die GUI stellt.

Danke schonmal für eure Hilfe!

Benutzeravatar
Tintom
Beiträge: 1433
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: XEN vs. QEMU+KVM

Beitrag von Tintom » 14.01.2018 18:49:41

Virtualbox kannst du auch headless "bedienen". Dann müsstest du dich nicht in neue Lösungen einarbeiten.

NAB
Beiträge: 5502
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: XEN vs. QEMU+KVM

Beitrag von NAB » 14.01.2018 19:59:10

Eine Empfehlung möchte ich nicht geben, da ich von XEN zu wenig Ahnung habe.

Zu KVM/virt-manager:
Das Zauberwort lautet hier nicht "virt-manager" sondern "libvirt" beziehungsweise "virsh" - das ist die Shell zu libvirt. Darüber kannst du die VMs auch komplett über Konsole und Texteditor konfigurieren und managen. "virt-manager" ist nur eine aufgepropfte aber zugegeben ziemlich praktische GUI. Sie erspart dir ellenlangen XML-Code.

Wirklich Spaß macht das Tippen über virsh aber nicht, da denkt man schnell über Scripte zur Automatisierung nach und landet in der Konsequenz dann bei sowas wie Proxmox.

> Weiß wer ob die Authentifizierung auch per ssh Key statt Passwort?
Höm? Welche Authentifizierung?
Du authentifizierst dich am Host per Username und dann halt SSH Key statt Passwort, ganz normal.
Ob du auf die VMs zugreifen darfst, entscheidet deine Gruppenzugehörigkeit:
https://wiki.debian.org/KVM

> Was wäre denn für VMs mt GUI zu empfehlen?
Wieviel GUI hätten Sie denn gerne?;)
virt-manager ist "auch nur ein X-Programm". Du kannst es dir mit ssh -X rüberholen. Wirklich Freude wird da aber nur im GBit-LAN aufkommen. Und wenn du schon im LAN unterwegs bist, kannst du auch XDMCP nehmen, wahlweise auf den Host oder auf den Linux Guest.
Sonst gibt's die üblichen Verdächtigen ... VNC, RDP.
Und das übliche Problem: kein Audio (da kann man sich mit Pulseaudio was basteln)

Der letzte Absatz gilt übrigens genau so für Virtualbox ... also ... joa, siehe Tintom.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

fireburner
Beiträge: 111
Registriert: 01.12.2017 20:51:31
Lizenz eigener Beiträge: neue BSD Lizenz
Wohnort: der wilde Süden

Re: XEN vs. QEMU+KVM

Beitrag von fireburner » 14.01.2018 22:15:01

Danke schon mal soweit.
Nunja, Virtualbox ist schön und toll, aber wenn es um Effizienz und Leistungsfähigkeit geht schneiden Hardware Nahe Hypervisoren deutlich besser ab.
Zusätzlich ist das ganze Projekt aber auch dazu gedacht sich neues Wissen anzueignen.

Das mit der Authentifizierung bezog sich rein auf virt-manager, den ich mir ja am Desktop installieren kann und dort eben Remote VMs managen kann.
Aber die Idee den virt-manager am host zu installieren und per ssh -X auszuführen klingt auch nicht verkehrt.

Wie schon erwähnt laufen hauptsächlich Services in den VMs die ohne GUI auskommen (VPN, caldav).
Die GUI VMs wären dann Windows oder reine Spielereien.

Benutzeravatar
weshalb
Beiträge: 822
Registriert: 16.05.2012 14:19:49

Re: XEN vs. QEMU+KVM

Beitrag von weshalb » 15.01.2018 00:35:58

Ich kann mich NAB anschließen, ich hatte am Anfang die virtuellen Maschinen mittels Webkonsole administriert, bin dann aber bei virsh auf der Konsole gelandet. Wenn man sich einmal damit beschäftigt hat, ist die Administration eigentlich recht logisch und einfach aufgebaut, zumal ich immer das Gefühl habe, Ressourcen gespart zu haben.

NAB
Beiträge: 5502
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: XEN vs. QEMU+KVM

Beitrag von NAB » 15.01.2018 04:06:47

fireburner hat geschrieben: ↑ zum Beitrag ↑
14.01.2018 22:15:01
Aber die Idee den virt-manager am host zu installieren und per ssh -X auszuführen klingt auch nicht verkehrt.
Ach, stimmt ... statt "virt-manager über ssh -X" zu machen kann man auch "ssh über virt-manager" machen. Damit hatte ich (vor vielen Jahren) Probleme, darum hab ich's mir anders herum angewöhnt ... das geht idiotensicher.

Die Sache ist verwirrend, es gibt je nach Tutorial zwei Methoden:

Die "alte" Methode verlangt einen root-Zugang zum Host per ssh:
https://docs-old.fedoraproject.org/en-U ... uests.html
Die funktioniert eindeutig mit Keys, hat eben den Nachteil des root-Zugangs und dafür den Vorteil, dass du einzelne VMs einzelnen Benutzern zuordnen kannst - libvirt fragt hier noch mal nach Benutzername und Passwort.

Für die "neue" Methode reicht ein ssh-Zugang mit einem einfachen Benutzer, der eben in den "libvirt"-Gruppen sein muss, dafür hat der dann Zugriff auf sämtliche VMs. Feinheiten muss man umständlich über PolicyKit einstellen (wenn man will):
https://fedoraproject.org/wiki/Getting_ ... management
Hier hat es mit den Keys bei mir nicht funktioniert, wobei ich eben einen Bugreport gefunden habe, der das erklären könnte:
https://bugzilla.redhat.com/show_bug.cgi?id=1532449
Überhaupt habe ich eben die Gebrauchsanweisung für die "Remote URIs" gefunden, also die Adressen um sich mit einer VM zu verbinden:
https://libvirt.org/remote.html
Über die URIs kannst du zig SSH-Parameter einstellen, was ja eben über die virt-manager GUI sonst nicht geht ... gut, dass ich das auch endlich mal erfahre :facepalm:

Daran siehst du aber auch wieder, dass virt-manager nur ne grob über libvirt drübergenagelte GUI ist. Wenn irgendwas nicht klappt, such nach Hilfen zu "libvirt", nicht zu "virt-manager".

Der Wunsch nach neuem Wissen hat mich auch zu libvirt getrieben ... und der Umstand, dass es eben nicht von Oracles Zickereien abhängig ist. Dabei fällt mir aber auch immer wieder auf, dass libvirt ziemlich komplex ist und für "wirklich große Dinge" gedacht ist. Auf der anderen Seite ist es dafür aber auch wieder zu kleinkariert ... niemand managed ein paar hundert VMs mit virsh. Dafür gibt's dann eben die großen Frameworks, die auf livbvirt aufsetzen. Da frag ich mich, was ich mit dem Wissen soll ... aber egal.

Virtualbox ist hardwarefern? Nunja, inzwischen belegt es den letzten Platz in den Benchmarks:
https://www.phoronix.com/scan.php?page= ... virt&num=1
Logisch, Oracle arbeitet ja auch kaum noch dran. Aber eine Schnecke ist es nun nicht. Aber ja, ich wollte auch weg davon, von dem sinkenden Schiff.
(Beim Vergleichen der Zahlen frage ich mich nebenbei, wie Citrix langfristig noch mit XEN Geld verdienen will)

Und was Windows und Spielereien angeht ... VirtualBox hat als Alleinstellungsmerkmal immer noch "ein bisschen" 3D-Beschleunigung. Und dafür gibt es sogar Windows-Treiber und es reicht für ein paar ältere Spiele. libvirt hat neuerdings auch "ein bisschen" 3D-Beschleunigung, aber das ist noch experimentell und es gibt keine Windows-Treiber (nur Linux). Auf der anderen Seite kann libvirt so coole Sachen wie eine ganze Grafikkarte an den Gast durchzureichen ... das hatte mich dann brennend interessiert. Das ist aber nichts, was du "remote" machen willst.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
weshalb
Beiträge: 822
Registriert: 16.05.2012 14:19:49

Re: XEN vs. QEMU+KVM

Beitrag von weshalb » 15.01.2018 07:58:15

NAB hat geschrieben: ↑ zum Beitrag ↑
15.01.2018 04:06:47
Dabei fällt mir aber auch immer wieder auf, dass libvirt ziemlich komplex ist und für "wirklich große Dinge" gedacht ist. Auf der anderen Seite ist es dafür aber auch wieder zu kleinkariert ... niemand managed ein paar hundert VMs mit virsh.
Und genau diese Kleinkariertheit finde ich wiederum super, wenn man nur 4-5 VM's am laufen hat, zumal die Befehle über Virsh für solche einfachen Zwecke in meinen Augen gar nicht einfacher sein können.

gugus
Beiträge: 263
Registriert: 04.09.2002 17:41:17
Wohnort: da wo ich zu Hause bin

Re: XEN vs. QEMU+KVM

Beitrag von gugus » 15.01.2018 19:08:21

Servus
Ich habe hier XEN mit Stretch am laufen, alles nur Server sprich ohne graphische Oberfläche.
Firewall über Webapp, Fileserver mit separater Festplatte, Cloudserver via Webapp und für ab und an ein Windows 7.
Alles via vncviewer erreichbar.
Gruss
gugus

Benutzeravatar
weshalb
Beiträge: 822
Registriert: 16.05.2012 14:19:49

Re: XEN vs. QEMU+KVM

Beitrag von weshalb » 15.01.2018 20:34:14

VNC nehme ich tatsächlich nur zum Einrichten. Später manage ich die Maschinen dann lieber über SSH oder bei Micrsoft über RDP, denn irgendwie werde ich mit dem VNC nicht richtig warm.

fireburner
Beiträge: 111
Registriert: 01.12.2017 20:51:31
Lizenz eigener Beiträge: neue BSD Lizenz
Wohnort: der wilde Süden

Re: XEN vs. QEMU+KVM

Beitrag von fireburner » 15.01.2018 22:07:37

Danke für die ganzen Informationen.

(Das mit dem GPU durchreichen ist ne tolle Sache, aber wie schon erwähnt bei nem Server nicht relevant. Aber weils angesprochen wurde: Das wird mein neues Projekt am Desktop, sobald ich eine non K Ivy Bridge CPU bekommen habe. Dann fällt der letzte Grund für ein DualBoot mit Windows weg und ich kann in der VM zocken.)

Ich denke ich werde es mal mit QEMU+KVM versuchen und mir virsh ansehen.
Um die VM beim Erststart einrichten zu können bleibt dann VNC oder virt-manager übrig, richtig?
Solange eben, bis ssh läuft.

NAB
Beiträge: 5502
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: XEN vs. QEMU+KVM

Beitrag von NAB » 15.01.2018 22:28:03

fireburner hat geschrieben: ↑ zum Beitrag ↑
15.01.2018 22:07:37
Um die VM beim Erststart einrichten zu können bleibt dann VNC oder virt-manager übrig, richtig?
Solange eben, bis ssh läuft.
Nunja ... die VM besteht aus einer XML-Datei und lebt in einer Image-Datei auf der Festplatte. Du könntest beides auch auf dem Desktop vorbereiten, rüberkopieren und per virsh importieren. Das ginge dann ganz ohne "remote GUI".

Das kann man natürlich auch noch umständlicher gestalten, google mal nach "unattended install", "automated install" oder "remote install".
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Antworten