Hat man früher im PC verschiedene Betriebssysteme gleichzeitig
auf verschiedenen Platten oder verschiedenen Partitionen gehabt,
bestand immer die Gefahr der gegenseitigen Beeinflussung.
Beispielsweise konnte man sich fast sicher sein,
dass der Linux-Bootloader nach der Windows-Installation
stumpf überschrieben wurde.
Die Linux nfts-Treiber waren früher noch ein wenig buggy,
sodass es bei Fremdzugriff leicht zu Datenschrott kam.
Ein gleichzeitiger Betrieb verschiedener Betriebssystem ist quasi ausgeschlossen.
Das heißt im Moment des Bootens muß man sich entscheiden...
Anders sieht die Situation aus wenn man
verschiedenen Betriebssystemen virtuelle Hardware anbietet.
Ich kann vom Host-System aus entscheiden,
was der virtuellen Umgebung zur Verfügung gestellt wird
(z.B. Netzwerk, Tauschlaufwerk, Speicher & CPU-Kerne, etc.).
Es ist möglich mehrere voneinander abgeschottete Gast-Systeme
gleichzeitig zu betreiben, aber benötigt nur eine Hardware.
Wenn Windows mal wieder nicht runter fahren will
wegen irgendwelcher Updates, muss ich nicht warten,
sondern kann zu jedem Zeitpunkt eine Session einfrieren und sie später fortsetzen.
Ebenso sind sogenannte Snapshots möglich,
zu denen ich wieder zurückgehen kann um
gewisse Veränderungen ungeschehen zu machen.
Virtualisierungs-Klassiker sind meines Erachtens
Vmware.com und
VirtualBox.org.
Mittlerweile tummeln sich hier noch etliche weitere technische Lösungen,
wobei ich hier nicht drauf eingehen möchte was die Unterschiede sind,
wo Emulation anfängt, welche Ebenen der Virtualisierung es gibt, etc..
Mit VirtualBox habe ich die meisten Jahre Erfahrungen und Kummer
sammeln können, daher hier eine
VirtualBox-Anleitung.
VM-Ware, verwendete ich in der Firma und zickt ab und zu auch mal rum...
Noch nicht so lange benutzte ich die opensource-Lösung
KVM - kernel-based virtual machine, welche mein Nachfolger ist.
Je nach Anwendung, ist es einfacher eine VM - virtual machine über ein
CLI - command line interface wie die Kombination
KVM & Virsh zu bedienen
oder per GUI - graphical user interface mit der Kombination
KVM & VM-Manager.
Nachfolger vom virt-manager wird wahrscheinlich
KVM & Cockpit.
Eine unter Umständen ausreichende Spezial-Lösung um
Windows-Programme auf Linux lauffähig zu machen, findet man auf folgender Seite
winehq.org
WINE - Wine Is Not an Emulator
Ich persönlich jedoch, bevorzuge eine saubere Trennung
von Produktiv-System (DEB) und temporären oder
mit Fremdsoftware angereicherten Systemen.
Das heist, sobald etwas ausserhalb der üblichen Software benötigt wird,
welches sich nicht in den Paketen befindet,
weiche ich auf ein virtualisiertes System aus.
Eigentlich schon fast wie selbstverständlich,
gehe ich davon aus das die CPU (> Jahr 2000)
entsprechende Befehle zur Virtualisierung beherrscht.
Im einfachsten Fall ist die Befehls-Erweiterung lediglich im BIOS deaktiviert.
Je nach CPU (AMD/Intel) muss nach einer anderen
Zeichenkette oder String gesucht werden.
Wird im Text "vmx" gefunden, steht Intel VT zur Verfügung,
entsprechend bei AMD heißt die Erweiterung für "svm" AMD-V.
Ist weder die ein noch die andere Endung zu entlocken,
ist Hardware Virtualisierung z.B. mit VirtualBox zwar möglich,
aber ungenießbar langsam.
Mit kvm ist es ähnlich, sollte keine Ausgabe kommen,
wie z.B. bei meinem ca. 14 Jahre alten T60 Laptop,
ist Hardware Virtualisierung mit KVM nicht erträglich möglich
(verwendet dann QEMU).
grep svm /proc/cpuinfo Beispiel für AMD ohne Markierung
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr…
svm… 4x bei vier AMD-Kernen
egrep '(vmx|svm)' --color=always /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology
tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64
monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe
popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch cpuid_fault
cat_l2 ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase
tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni xsaveopt
xsavec xgetbv1 xsaves dtherm ida arat pln pts md_clear arch_capabilities
für einen Intel-Prozessor mit 4 Kernen, wiederholt sich der Text 4 Mal
Entsprechend der Anzahl an CPU-Kernen wiederholt sich die obige gekürzte Meldung.
Anbei eine wesentlich kürzere Möglichkeit zu überprüfen,
ob die CPU Hardwarevirtualisierung beherrscht.
Ist alles in Ordnung, sind zwei Kernel-Module (hier kvm_amd & kvm) vorhanden.
lsmod | grep kvm kvm_amd 2183168 0 kvm 606208 1 kvm_amd Antwort AMD-V irqbypass 16384 1 kvm
Für Intel sieht es vergleichbar aus. Zwei Kernel-Module: (hier kvm_intel & kvm)
lsmod | grep kvm kvm_intel 233472 8 kvm 757760 1 kvm_intel irqbypass 16384 5 kvm
Noch eleganter kann man mit folgenden Befehl feststellen,
ob die CPU (hier intel) mit der jetzigen BIOS-Einstellung, Virtualisierung beherrscht.
Zudem sehe ich auch ob 64 Bit möglich sind.
lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 92 Model name: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz Stepping: 9 CPU MHz: 1122.746 CPU max MHz: 2300.0000 CPU min MHz: 800.0000 BogoMIPS: 2995.20 Virtualization: VT-x L1d cache: 24K L1i cache: 32K L2 cache: 1024K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae…
Zum Anfang
Ein weiterer Aspekt wäre die Frage ob eine 64 Bit-CPU oder noch eine 32-Bit-CPU verbaut ist.
Auch hierfür gibt es verschiedene Möglichkeiten.
grep " lm " --color=always /proc/cpuinfo lm - long mode = 64 Bit
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc …
grep -o -w 'lm' /proc/cpuinfo
lm
lm
lm
lm für vier 64 Bit CPU-Kerne
uname -a 386/486/… steht für 32 bit Kernel
Linux gj2 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
getconf LONG_BIT
64
Zum Anfang