Am 29.04.21 um 12:28 schrieb Ulf Volmer:

On 29.04.21 11:43, Jörg Thümmler wrote:

...

AFAIK musst Du z.B. für die KVM-Sachen und QEmu einen anderen Kernel haben, während VirtualBox mit dem StandardKernel läuft.

Nein, die laufen mit dem Standard- Kernel. Das ist aus meiner Sicht auch einer der Vorteile von libvirt/KVM, dass man da keine Drittsoftware benötigt. Und man sich das bauen der benötigten Kernel Module sparen kann.

Viele Grüße Ulf

OK, es kann sein, dass mir das schon vmware eingebrockt hatte und ich es nicht gleich gesehen und auf die anderen geschoben habe, Asche auf mein Haupt. -- cu jth

Mathias Homann schrieb:

...

AFAIK musst Du z.B. für die KVM-Sachen und QEmu einen anderen Kernel haben, während VirtualBox mit dem StandardKernel läuft.

Da verwechselst du KVM und XEN. KVM ist im Standardkernel drin, für XEN brauchst du eine Extrawurst.

Das ist mehr als ein Jahrzehnt her, dass man für Xen spezielle Kernel brauchte, das Gerücht, dass das immer noch so sei, hält sich leider hartnäckig. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Mathias Homann <Mathias.Homann@opensuse.org> wrote:

Am Donnerstag, 29. April 2021, 11:20:46 CEST schrieb Kyek, Andreas

...

Derzeit läuft bei mir (Laptop) im Hintergrund ein Server (leap 15.2). Auf dem Server gibt es u.a. zwei Windows und eine Linux VirtualBox VM

...

Was wäre jetzt der Vorteil auf z.B. KVM (oder Xen?) umzusteigen? Oder ist meine Lösung gar nicht so schlecht?

Ich drück das jetzt mal ganz "un-IT-isch" aus:

Stell Dir vor du hast ein Schlauchboot mit einem Aussenbordmotor - und wenn du damit von A nach B willst, nimmst du einen ANDEREN Außenbordmotor, der eventuell ein gaaanz kleines bisschen einfacher zu bedienen ist aber dafür dann nicht so viel Leistung aus der gleichen Menge Benzin holt.

Es wird funktionieren, es wird auch bestimmt gute Gründe dafür geben - aber irgendwie blöd ist es trotzdem...

Netter Vergleich - macht es einem alten IT-Laien doch gleich viel einfacher:-) (OK; mein Inf Studium ist wirklich ein paar Tage her) Aber welcher Aussenbordmotor ist denn nun welcher in deinem Vergleich? Andreas C2 General

Am 29.04.21 um 23:15 schrieb Richard Hafenscher:

...

Am 29.04.21 um 11:20 schrieb Kyek, Andreas, Vodafone DE:

Ich habe beides, Virtualbox und KVM/Qemu, verwendet. Im Prinzip, kann man Virtualbox-guests zwischen Windows- und Linux-hosts austauschen.

Aber wer will das schon? ;-)

Sollte man tatsächlich eine VM auf ein anderes System portieren müssen, kann man die virtuellen Qemu Disks konvertieren, jedenfalls in der Konsole. qemu- img beherrscht einige Zielformate anderer Systeme. Ich habe so VMs von KVM auf VirtualBox oder ESXi gebracht.

Vor einger Zeit getestet und an KVM/Qemu => VirtualBox gescheitert. Virtualbox konnte das erstellte RAW-Format nicht lesen.

Die VM-Konfiguration muss man aber neu erstellen.

Das wäre nicht das Problem.

...

...

Der Datenaustausch zwischen Guest und Host ist so nicht vorgesehen, man kann ihn aber einrichten, einfach für Linux <=> Linux, für Linux <=> Windows mit Samba oder SneakerNet (USB) oder Copy&Paste. Komfort ist etwas anderes, aber hier wohl nicht das Ziel.

Habe gelesen, dass es für Windows auch schon 9P/VirtFS-Treiber gibt, so dass der Host dem Gast ein Verzeichnis bereitstellen kann, das im Gastsystem eingebunden wird.

Ja, gelesen habe ich das auch:-(

Aber den Komfort von VirtualBox bietet das auch nicht. ... VirtualBox mag etwas einfacher zu handhaben sein (wenngleich auch nicht für mich) und ist, weil es für alle gängigen Betriebssysteme verfügbar ist, stark verbreitet. KVM ist bestens für Serverbetrieb geeignet. Ich ziehe es aber auch am Desktop VirtualBox vor. Auf Linux scheint KVM auch weniger Probleme zu machen als VirtualBox. Von letzterem liest man immer wieder, dass es nach einem Kernel-Update nicht mehr arbeitet. Das gibt es bei KVM nicht, das ist Teil des Kernels.

Ich habe das nur von Tumbleweed gelesen, bei der von openSUSE mitgelieferten Standard-VirtualBox-Version in den div. Leap ist mir das nie passiert, Zusätzlich braucht man halt immer bei Updates den passenden Extension-Pack von Virtualbox. Das ist allerdings jammern auf hohem Niveau. Peter

Grüße Richard

Am 02.05.21 um 09:34 schrieb Tobias Crefeld:

Am Fri, 30 Apr 2021 15:57:51 +0200 schrieb Peter McD <peter.posts@gmx.net>:

...

Am 29.04.21 um 23:15 schrieb Richard Hafenscher:

...

...

Am 29.04.21 um 11:20 schrieb Kyek, Andreas, Vodafone DE:

...

...

Sollte man tatsächlich eine VM auf ein anderes System portieren müssen, kann man die virtuellen Qemu Disks konvertieren, jedenfalls in der Konsole. qemu- img beherrscht einige Zielformate anderer Systeme. Ich habe so VMs von KVM auf VirtualBox oder ESXi gebracht.

Vor einger Zeit getestet und an KVM/Qemu => VirtualBox gescheitert. Virtualbox konnte das erstellte RAW-Format nicht lesen.

IIRC muss man ein Image im raw-Format mit vboxmanage nach VDI oder VMDK konvertieren. ...

Danke, das wird es gewesen sein. Teste ich gelegentlich Gruß Peter

Am Fri, 30 Apr 2021 08:56:20 +0000 schrieb Rolf Schumann <schumann.rolf@posteo.de>:

ich wundere mich, dass hier XEN offensichtlich gar keine Rolle mehr spielt. siehe: https://www.linux-magazin.de/ausgaben/2017/12/xen/ oder https://www.computerweekly.com/de/tipp/Xen-oder-KVM-ist-2019-ueberhaupt-kein...

Es scheint nicht mehr in Mode zu sein, obwohl es wie KVM eingerichtet wird (und Sicherheitsvorteile hat?).

Oder gibt es noch andere Gründe?

SUSE hat XEN sehr früh unterstützt und aus der Zeit stammen wohl bei den meisten die entsprechenden Erfahrungen. XEN lief damals "native" und bot nur Paravirtualisierung, bei der alle Guests dasselbe Linux wie der Host hatten. Funktional vergleichbar mit Docker also. Was damals als Vorteil gepriesen wurde, weil weniger Storage, RAM und (vor der Einführung der Virtualisierungsbeschleunigungen wie vmx, etc.) Performance gebraucht wird, hat sich für die meisten als Einschränkung der Flexibilität erwiesen, weil man nicht mal nur eine VM patchen konnte, von anderen OS wie MS-Win oder BSD ganz zu schweigen. KVM kam dagegen gleich mit Qemu daher, die neuen CPU-Features sorgten für mehr Performance und als Gesamteindruck blieb hängen, dass KVM besser ist als XEN. Und niemand braucht auf die Dauer zwei Virtualisierungsplattformen. Welche Sicherheitsvorteile soll XEN bieten? -- Gruss, Tobias Crefeld. xmpp (no email): crefeld@xabber.de

On Sun, 2 May 2021 09:50:06 +0000 Rolf Schumann <schumann.rolf@posteo.de> wrote:

Am 02.05.21 um 10:00 schrieb Tobias Crefeld:

...

Welche Sicherheitsvorteile soll XEN bieten? aus Linuxmagazin:

"Anders bei KVM: KVM koordiniert im Kernel etwa den Zugriff auf RAM und CPU selbst. Der Hostkernel sieht immer die gesamte Hardware. Eine Amok laufende VM kann dadurch andere VMs stören. Das gilt sogar für direkt an eine VM durchgereichte Hardware. Wer also bei KVM etwa einzelnen VMs eigene NICs zur Verfügung stellt, hat nicht die Garantie, dass eine über diese NICs stattfindende Attacke nicht das Hostsystem und damit andere VMs beeinflusst.

In Xen ist das anders: Weil der Hypervisor die Hardware verwaltet, ist sicher, dass wirklich nur die jeweilige VM beeinflusst wird, der die NIC zugeordnet ist."

Sorry, den Artikel hatte ich nicht gelesen. Halte den Text für irreführend, weil er suggeriert, dass es bei XEN einen Hypervisor gäbe und bei KVM nicht. Ist natürlich Quatsch, weil KVM _ist_ der Hypervisor, ordnet also den VMs die Resourcen zu. Alle mir bekannten x86-basierten Virtualisierer arbeiten mit einem Kernel, auf dem ein Hypervisor läuft. Es gibt Unterschiede hinsichtlich der Frage, ob er dort im User-Space und/oder Kernel-Space läuft, aber einen Kernel gibt es überall. Die Zuordnung von Resourcen klappt bei allen moderneren x86-Hypervisor zuverlässig. Dass eine "Amok laufende" VM den Host bzw. die anderen VM runter zieht, ist mir schon lange nicht mehr untergekommen. Ausbrüche aus einer VM mit Übernahme des Hostkernel sind mir bislang nur als Proof-of-Concept bekannt, für das etliche Voraussetzungen gegeben sein müssen. Kritisch und am ehesten Quelle für Instabilitäten sind hardware-nahe Dinge wie die Einbindung von Adapterkarten via PCI-passthrough, wo Hardware außerhalb der Hypervisor-Kontrolle durchgereicht wird. Es gibt in Hardware bzw. Firmware gegossenen Hypervisor, die tatsächlich keinen Kernel haben, der manipuliert werden könnte, z.B. LPAR von IBM. Besonders bei den frühen Implementierungen waren die Resourcen-Zuordnungen sehr statisch. Dafür hast Du die Dinger selbst mit roher Gewalt nur schwer zum Systemstillstand bringen können. Das ging (geht?) soweit, dass in Tabellen festgelegt werden musste, welche Logical Partition (=VM) welchen RAM-Adressbereich nutzen darf.

Unterschiedliche Gastsysteme: wir benutzten Debian als dom0 für XEN, worauf Windows und Ubuntu als Gastsysteme liefen. Das ist nun Geschichte, aber unzufrieden waren wir damit nicht...

Wie gesagt, das kommt darauf an, welches XEN man meint. Traditionell mussten die VMs alle dasselbe OS wie die dom0 nutzen. Ihr hattet hingegen XEN mit Qemu. Qemu bietet hier die nötige Vollvirtualisierung, die man benötigt, um VMs mit anderen OS zu betreiben. Bei den frühen Installationen hat das jeder vermieden, weil es deutlich Performance gekostet hat. Der Punkt fiel erst mit der Verbreitung von CPUs mit den Virtualisierungsfeatures nicht mehr ins Gewicht. Ich hatte vor ein paar Jahren ein Altsystem zu betreuen, dass noch mit einem traditionellen XEN-Setup arbeitete. Dort die VMs (alias dom) so zu extrahieren, dass sie in einem Vollvirtualisierer lauffähig sind, war schon eine besondere Herausforderung. IIRC haben wir am Ende lieber die Notwendigkeit zur Beibehaltung des Systems wegdiskutiert. ;) Gruß, Tobias.

Tobias Crefeld schrieb:

SUSE hat XEN sehr früh unterstützt

Suse unterstützt Xen immer noch. Sprich, einige der Xen-Entwickler sind bei Suse angestellt.

XEN lief damals "native"

???

und bot nur Paravirtualisierung,

Klar, da es noch keine Hardware-Unterstützung für Virtualisierung gab.

bei der alle Guests dasselbe Linux wie der Host hatten. Funktional vergleichbar mit Docker also.

Nein, das stimmt überhaupt nicht! Die paravirtualisierte VM hatte (und hat, denn das geht immer noch) einen eigenen Kernel, aber eben einen angepassten. Und genau deshalb spukt immer noch in den Köpfen vieler Leute die falsche Idee rum "Xen braucht einen speziellen Kernel und das will ich nicht".... Und dass es damals - also so in der ersten Hälfte der Nuller Jahre - gewisse Versions-Abhängigkeiten zwischen VM- und Host-Kernel (und Xen-Version) gab, lag an der schnell fortschreitenden Weiter-Entwicklung in der frühen Phase. Aber grundsätzlich konnte die VM eine andere Kernel-Version fahren wie der Host.

Was damals als Vorteil gepriesen wurde, weil weniger Storage, RAM und (vor der Einführung der Virtualisierungsbeschleunigungen wie vmx, etc.) Performance gebraucht wird,

Das stimmt auch nicht, da es sich eben um eine vollwertige VM gehandelt hat. Vorteil war damals (also bevor es Hardware-Virtualisierung gab) die etwas bessere Performance im Vergleich zu Virtualisierungs-Software, die eine Binary Translation machen musste.

KVM kam dagegen gleich mit Qemu daher, die neuen CPU-Features sorgten für mehr Performance und als Gesamteindruck blieb hängen, dass KVM besser ist als XEN.

Das stimmt leider auch überhaupt nicht. Dass KVM sich gegen das damals schon technisch ausgereiftere Xen ganz gut durchgesetzt hat, war eigentlich ausschließlich eine politische Angelegenheit. KVM wurde von Qumranet entwickelt und wurde dann von RedHat aufgekauft und die haben es mit ihrer Marktmacht bei Linux-Distributionen (vor allen Dingen im kommerziellen Umfeld!) massiv "gehypet" und tun das auch heute noch. Xen wurde von der Universität Cambridge entwickelt, die dazu eine Firma namens XenSource gegründet hat. Die wurde später von Citrix übernommen. Auch Citrix "wollte" Xen wohl aus marktpolitischen Gründen nicht hypen, da das wohl Firmen, mit denen Citrix zusammen arbeitete nicht soo recht war. Schließlich ging dann Xen an die LinuxFoundation. Und zum Thema qemu: KVM und Xen benutzen BEIDE qemu und zwar für den gleichen Zweck: Nämlich um bei Vollvirtualisierung Devices zu emulieren. Das ist aber eigentlich nur eine "Notlösung", denn emulierte Devices sind langsamer als paravirtualisierte. Das Performance-Optimum ist Hardware-Virtualisierung mit paravirtualisierten Treibern. Und da Xen aus der Paravirtualisierungs-Schiene kommt, haben die da die Nase (ein klein bisschen) vorn. Trotzdem ist auch der Hardware-Virtualisierungs-Support von Xen grandios und äußerst stabil!

Und niemand braucht auf die Dauer zwei Virtualisierungsplattformen.

Konkurrenz belebt das Geschäft... :-) Es gibt ja auch mit KDE und GNOME zwei (große) Desktops für Linux und noch viele kleine. Jeder nimmt halt das, was er braucht...

Welche Sicherheitsvorteile soll XEN bieten?

Das fängt schon mal damit an, dass der Xen-Hypervisor beim Booten noch vor dem Kernel des Hosts geladen wird, sprich, der Host ist eigentlich die erste VM auf dem System mit definierten Schnittstellen zum Hypervisor. KVM ist integrierter Bestandteil des Kernels des Hosts (letztendlich ein Kernel-Modul) und damit über jede Schwachstelle des Host-Kernels angreifbar. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel