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

Hallo,

angeregt durch den Thread "Welche Virtualisierungssoftware", den ich aber nicht kapern wollte, hier mal meine Frage:

Seit 2 Tagen lese ich u.a. viel in der opensuse Dokumentation zu Virtualisierung - und ehrlich: ich weiss nicht wirklich was man tun sollte.

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 (Früher mal vmware; aber das läuft nicht mehr auf der alten CPU des Servers) Eine Windows VM sozusagen "Produktion" - damit mache ich Bankgeschäfte, Steuern etc. Der Rest ist zum Spielen.

Normalerweise starte ich diese VMs "headless" und hole mir dem Schirm mit xfreerdp auf den Laptop. (früher mal mit Remmina - aber das Teil zickt hier rum) Und eigentlich laufen alle meine Programme zufriedenstellend.

An den Server gehe ich eigentlich physisch fast nie ran (der hat noch nicht mal einen Monitor)

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

Wo kann ich Information finden, die mir z.B. aufzeigen, das VirtualBox hier sein Stärken und da seine Schwächen im Vergleich zu anderen hat? (Vielleicht sehe ich ja auch den Wald vor lauter Bäumen nicht - es gibt einfach zu viele Artikel dazu.)

Any hints are welcome - auch ein RTFM

Andreas

C2 General

Ich kann und will mich hier Andreas nur anschließen... Auf meinem Rechner (desktop PC) läuft native Leap 15.1. Damit mache ich 80% meiner Arbeit. Für die restlichen 20%, Dinge für die ich WIN benützen MUSS, weil ich bis heute leider keine (brauchbaren) Linux-Alternativen gefunden habe, läuft in einer Virtualbox WIN-7. Jetzt gibts aber auch noch KVM, und XEN, und ..... Was soll / kann / darf man wofür verwenden? Vorteile? Nachteile? Ich denke, in diesem Wald stehen sehr viele Bäume... Norbert

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

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

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... -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

Mathias Homann 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 11:20 schrieb Kyek, Andreas, Vodafone DE:

... Wo kann ich Information finden, die mir z.B. aufzeigen, das VirtualBox hier sein Stärken und da seine Schwächen im Vergleich zu anderen hat? (Vielleicht sehe ich ja auch den Wald vor lauter Bäumen nicht - es gibt einfach zu viele Artikel dazu.)

Wie bei Radio Eriwan, es kommt darauf an: Ich habe beides, Virtualbox und KVM/Qemu, verwendet. Im Prinzip, kann man Virtualbox-guests zwischen Windows- und Linux-hosts austauschen. Das ist nett, wenn man Probleme mit einem der Wirte bekommt und auf die Schnelle wechseln muss. Setup von Virtualbox fand ich simple, ebenso der Datenaustausch zwischen Host und Guest, ist aber vielleicht ein Sicherheitsproblem. Um die Updates muss man sich kümmern. Setup von Guest dürfte bei beiden gleich einfach sein. KVM/Qemu ist angeblich fixer und keine Fremdsoftware wie Virtualbox, Updates kommen wie üblich bei Linux. 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. Mein Tipp: Für einfachen Ansprüchen, z.B. die jährliche Steuererklärung, reicht Virtualbox Peter

Hallo

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. Die VM-Konfiguration muss man aber neu erstellen.

KVM/Qemu ist angeblich fixer und keine Fremdsoftware wie Virtualbox, Updates kommen wie üblich bei Linux.

Probleme habe ich allerdings am Desktop zeitweise mit dem Netzwerk mit NM. Das ist manchmal nicht verfügbar bis ich die Kiste neu starte. Ich denke aber, das liegt zum einen an NM und zum anderen daran, dass ich den Rechner meist nur in Standby schalte. Am Server, wo ich Wicked verwende, gibt es diese Probleme nicht.

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. Aber den Komfort von VirtualBox bietet das auch nicht.

Mein Tipp: Für einfachen Ansprüchen, z.B. die jährliche Steuererklärung, reicht Virtualbox

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. Grüße Richard

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 Fri, 30 Apr 2021 08:56:20 +0000 schrieb Rolf Schumann :

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

Hallo, Tobias, 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." 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... Viele Grüße Rolf

On Sun, 2 May 2021 09:50:06 +0000 Rolf Schumann 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.