Linux Mint in VirtualBox 7 unter Windows 10

foofoobar schrieb:
Das "ursprüngliche" Windows sieht dann also nur noch virtuelle HW?
Die drei Sätze im zweiten Absatz hier.
foofoobar schrieb:
Und wie installiert man dann Treiber für neue physikalische Hardware?
Das ist ja das tolle an einem level 1 Hypervisor. Je nach Einrichtung/Privilegien kann er steuern, ob ein Gastsystem virtualisierte oder mit direkten durchreichen physikalische Hardware im Zugriff hat.

Deshalb ja für das ganze GPU-Pathtrough relevant weil eben der Hypervisor eine GPU gänzlich an das Gastsystem übergeben kann.
 
Zuletzt bearbeitet:
Keylan schrieb:
Laut dieser Definition (auf die ich mich bezog) ist es das nicht.
Hypervisor.png

Keylan schrieb:
Entscheidend ist nach meinem Verständnis der direkte Zugriff auf sämtliche Hardware ohne Zwischenschicht.
Ist ja bei Virtmanger/Qemu auch nicht out of the box gegeben. Um direkt auf eine Grafikkarte zugreifen zu können muss man ja einiges veranstalten.

Gruß
R.G.
 
rgbs schrieb:
Ist ja bei Virtmanger/Qemu auch nicht out of the box gegeben. Um direkt auf eine Grafikkarte zugreifen zu können muss man ja einiges veranstalten.
GPU ist etwas aufwendiger, z.b. eth oder usb funzt per Klick im virt-manager.
Ergänzung ()

Keylan schrieb:
Das ist ja das tolle an einem level 1 Hypervisor. Je nach Einrichtung/Privilegien kann er steuern, ob ein Gastsystem virtualisierte oder mit direkten durchreichen physikalische Hardware im Zugriff hat.
VBox kann auch HW durchreichen, soll aber ein Typ 2 sein.
 
rgbs schrieb:
Laut dieser Definition (auf die ich mich bezog) ist es das nicht.
Wie gesagt, kenne ich mich mit den Details bei KVM nicht aus, aber der markierte Teil steht nicht im Konflikt mit dem Fakt, das Hyper V ein level-1 Hypervisor ist.

Bei KMV verlasse ich mich einfach auf die Aussage, das dieser (genau wie Hyper V) überall als level 1 Klassifiziert ist.
foofoobar schrieb:
VBox kann auch HW durchreichen, soll aber ein Typ 2 sein.
Ich mache die Klassifizierung nicht.
Ich vermute es liegt daran, das VirtulBox noch immer auf die Ressourcen des Host-Systems angewiesen ist und nur PCIE Schnittstellen durchreichen kann.
Bei level 1 wird Sämtliche Hardware erst mal vom Hypervisor erkannt und verwaltet und dabei ggf. an die Gast Systeme übergeben.

Hier werden die level Vergleichen und auch Beispiele aufgeführt.
 
Zuletzt bearbeitet:
Keylan schrieb:
aber der markierte Teil steht nicht im Konflikt mit dem Fakt, das Hyper V ein level-1 Hypervisor ist.
Wie kriege ich denn Hyper V auf die Kiste, ohne vorher Windows zu installieren?

Gruß
R.G.
 
Keylan schrieb:
Hier werden die level Vergleichen und auch Beispiele aufgeführt.
Das steht doch auch wieder Bullshit:

Pros & Cons of Type 1 Hypervisor​

Type 1 hypervisors offer important benefits in terms of performance and security, while they lack advanced management features. Following are the pros and cons of using this type of hypervisor.

Pros​

  • VM Mobility - Type 1 hypervisors enable moving virtual machines between physical servers, manually or automatically. This move is based on the resource needs of a VM at a given moment and happens without any impact on the end-users. In case of a hardware failure, management software moves virtual machines to a working server as soon as an issue arises. The detection and restoration procedure takes place automatically and seamlessly.
  • Security - The type 1 hypervisor has direct access to hardware without an additional OS layer. This direct connection significantly decreases the attack surface for potential malicious actors.
  • Resource Over-Allocation - With type 1 hypervisors, you can assign more resources to your virtual machines than you have. For example, if you have 128GB of RAM on your server and eight virtual machines, you can assign 24GB of RAM to each. This totals 192GB of RAM, but VMs themselves will not consume all 24GB from the physical server. The VMs detect they have 24GB when they only use the amount of RAM they need to perform particular tasks.
Das kann auch alles kvm, aber das ist laut dieser Seite ein Typ 2.
 
Tja, die Welt ist nicht immer schwarz und weiß. Und auch für die Fehlerfreiheit des Artikels bin ich nicht Verantwortlich. Den KVM Part hatte ich übergangen.

Aber es ist etwas speziell bei KVM, Da als Bestandteil von QEMU level 2, für sich genommen aber nach Definition level 1. Wiki

Es hängt wie schon zuvor geschrieben nicht von der Software selbst, sondern von der Einrichtung ab.

Mit Proxmox VE betreibt man KVM als level 1 Hypervisor. Mit QEMU wohl idr. als level 2.

War mir bisher auch nicht bewusst, und ich hatte mich einfach auf die Klassifizierung verlassen, obwohl ich nur QEMU/KVM nutzte.

Ich kann aber als Anekdote bestätigen, dass bei mir Virtualisierungen mit QEMU/KVM stabiler laufen als mit VirtualBox,
 
Zuletzt bearbeitet:
foofoobar schrieb:
Das kann auch alles kvm, aber das ist laut dieser Seite ein Typ 2.
Hm? Meinst du die verlinkte Seite? Dort steht doch bei KVM: "It is sometimes confused with a type 2 hypervisor." Man muss sich nur den Verzeichnisbaum der Linux-Kernel-Sourcen anschauen, um zu sehen, dass KVM integraler Bestandteil des Kernels ist. Das gilt für die VMware und VirtualBox-Module nicht.

Die Unschärfe kommt doch schlicht daher, dass bei der Definition von Typ 1- und Typ 2-Hypervisoren in der Doktorarbeit von Robert Goldberg die IT eine komplett andere war als heute. Und man kann daher zurecht die Frage stellen, warum man diese Bergriffe heute noch verwendet, owohl die Trennung heute weit weniger strikt ist.

Für mich bedeuten die Begriffe:
Typ 1: Ist das Betriebssystem
Typ 2: Benötigt ein Betriebssystem
 
Evil E-Lex schrieb:
warum man diese Bergriffe heute noch verwendet, owohl die Trennung heute weit weniger strikt ist.
Das sehe ich auch so, zumal es ja heutzutage VTx u.s.w. gibt.
Keylan schrieb:
Ich kann aber als Anekdote bestätigen, dass bei mir Virtualisierungen mit QEMU/KVM stabiler laufen als mit VirtualBox,
Meine Erfahrungen sind gegenteilig.

Gruß
R.G.
 
Zurück
Oben