QEMU/KVM in Debian 12

[ropf]

Moin,

wollte mir unter Debian 12 gerade eine virtuelle Windows-Maschine basteln. Die Anleitungen, die ich gefunden hab, erfordern alle das Paket qemu-kvm, aber das scheint es unter Debian12 nicht (mehr?) zu geben ...

Hat jemand einen Link zu einer einigermassen aktuellen Schritt-für-Schritt-Anleitung?

 

[oicfar]

https://reintech.io/blog/installing-using-kvm-virtualization-debian-12

 

[0x8100]

mit gui? https://forums.debian.net/viewtopic.php?t=158967

 

[pvalerio]

Ich versuche gerade dasselbe, mit virt-install konnte ich die VM anlegen und starten/installieren, aber ich kriege die Netwerkverbindung nicht hin... Wenn ich eine Bridge konfiguriere (über /etc/network/interfaces), egal wie, verschiedene Arten probiert, verliere ich die Netzwerkverbindung. Und mit network=direct klappt es auch nicht. Hat wer Tipps? Host und Guest beide Debian 12

Mein virt-install Befehl:

virt-install \
--name Debian12 \
--ram 4096 \
--disk path=/var/lib/libvirt/images/Debian12.img,size=20 \
--vcpus 4 \
--os-variant debian11 \
--network bridge=br0 \
--graphics none \
--console pty,target_type=serial \
--location /home/debian-12.6.0-amd64-netinst.iso \
--extra-args 'console=ttyS0,115200n8 serial'

 

[ropf]

Danke, hab die Variante mit gui aus dem debianforum installiert.
(Die Anleitung im reintech blog bezieht sich wieder auf das Paket qemu-kvm, das in den Paketquellen nicht vorhanden ist.)

Btw: Macht es Sinn, bzw. ist es möglich, der VM statt eines Datenträger-Abbilds eine physische Platte oder Partition unterzuschieben?

 

[DenB]

https://packages.debian.org/bookworm/qemu-kvm

Also hier ist es vorhanden.

Edit:
https://packages.debian.org/bookworm/amd64/qemu-system-x86/download

 

[bye]

Danke, hab die Variante mit gui aus dem debianforum installiert.
(Die Anleitung im reintech blog bezieht sich wieder auf das Paket qemu-kvm, das in den Paketquellen nicht vorhanden ist.)

Btw: Macht es Sinn, bzw. ist es möglich, der VM statt eines Datenträger-Abbilds eine physische Platte oder Partition unterzuschieben?

hi prinzipel möglich allerdings nicht unbedingt notwendig, was erwartest du dir davon?

 

[schrht]

Btw: Macht es Sinn, bzw. ist es möglich, der VM statt eines Datenträger-Abbilds eine physische Platte oder Partition unterzuschieben?

Ist es möglich? Ja. Macht es Sinn? Kommt ganz darauf an was du vor hast.

 

[ropf]

@schrht Kommt ganz darauf an was du vor hast

Na - ich hab im Laptop ne Sata-SSD, wo noch vom Vorbesitzer ein aktiviertes Windows drauf ist - und eine M.2-SSD mit Linux. Per default wird Linux gebootet, wenn ich gelegentlich Windows brauche, wähle ich das über das UEFI aus.

Funktioniert soweit ohne Probleme - es nervt nur, dass ich jedesmal neu booten muss, wenn ich mal Windows brauche. Deshalb die Idee, die Windows-Platte direkt einer VM unterzuschieben.

Ausserdem glaube ich, dass das mit weniger Overhead verbunden sein müsste, was auf dem doch älteren Gerät eine Rolle spielen mag

norrmal:
Windows/NTFS -> virtSCSI -> VM-Image -> Linux/ext4 -> Sata

direkt:
Windows/NTFS/Sata -> Virtulisierungslayer -> Sata (Hardware)

Ungefähr so, stecke aber nicht wirklich drin. Die SATA-SSD wird auschliesslich von Windows benutzt, Die M.2 ausschliesslich von Linux.

 

[Uridium]

Wenn Du das machst, findet Windows eine Tonne neuer Hardware, die einen Neustart benötigt. Und das jedes Mal, wenn Du zwischen echtem Boot und VM wechselst (wenn es überhaupt funktioniert). Und aktiviert ist das Windows dann auch nicht mehr.

Installier das sauber in der VM und schmeiß das andere weg, sofern du kein chkdsk für NTFS Partitionen brauchst.

 

[ropf]

Na - auf einen "echten Boot" würde ich dann verzichten - das ist ja der Sinn der Sache.

 

[Uridium]

Probieren kannst Du es. Aber aktivieren musst Du dennoch erneut.

Edit: Wobei ich nicht weiß, ob OEM Aktivierungen (falls zutreffend) überhaupt in der VM funktionieren. Früher war das so, dass der halbe Schlüssel im BIOS oder in der Hardware gewesen ist. Das würde alles nicht in der VM funktionieren.

Ein anderer Punkt, den man u.U. nicht außer Acht lassen sollte, sind "mixed NTFS" Partitionen (also NTFS Partitionen auf der Linux Bootplatte). Du kannst keine Blockdevices (einzelne Partitionen) in die VM hängen (kannst Du schon, Windows mag die aber nicht, bzw. nur ganze Datenträger mit Partitionstabelle etc). Das heißt, wenn Du ein chkdsk auf einer NTFS Partition, die auf der Bootplatte liegt, machen willst, geht das nicht so einfach mit einer VM. Da ist ein "echtes" Windows vielleicht noch nützlich.

 

[Aktaion]

Ich muss mal eben nachfragen, verstehe ich das richtig das du versuchst ein Windows das auf einem Laufwerk installiert ist, in eine VM zu verschieben?

 

[Uridium]

Nicht verschieben. Er möchte das Laufwerk direkt anbinden.

 

[Aktaion]

Achso ok, man kann ja neue Festplatten in eine VM einbinden, aber eine Festplatte mit bestehendem Windows, dass lese ich zum ersten mal.

 

[ropf]

Er möchte das Laufwerk direkt anbinden.

Genau. Windows neu aufzusetzen wär jetzt auch nicht problematisch, aber ich stell es mir einfach effizienter vor:

• dem NTFS-/SATA-Treiber auf der Windows Seite - über den Virtualisierungslayer - Zugriff auf die physische Platte zu geben
• anstatt ihm einen virtuellen Sata- oder SCSi-Controller vorzugaukeln - der die Zugriffe auf (virtueller) Hardwareebene von Windows - in Zugriffe auf Dateisystem-Ebene unter Linux - auf eine Datenträger-Abbild-Datei übersetzt - und erst von dort aus über die Linux-SATA-Treiber auf die physische Platte

-------------------

Die Frage ist - ob dieser Gedankengang überhaupt zutrifft - und ob sich der erhoffte Effizienzgewinn tatsächlich bemerkbar macht.

Im Augenblick schlag ich mich noch mit den Begrifflichkeiten herum. Im GUI kann ich einen "Pool" auf einer phyischen Platte anlegen, dort ein "Volume" erzeugen, dass dann automatisch ext4-formatiert wird ...

... aber das "Volume" (im virt-Manager) entspricht doch einer Partition unter Windows - und sollte NTFS-formatiert werden - oder nicht? Mir raucht gerade der Kopf.

 

[foofoobar]

@ropf Das wäre das einfachste:

<disk type="block" device="disk">
  <driver name="qemu" type="raw"/>
  <source dev="/dev/sda"/>
  <target dev="vda" bus="virtio"/>
  <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
</disk>

Was dein Windows mit der neuen "HW" macht sind allerdings wieder mal Windows-Dinge, Windows macht halt Windows-Dinge.

Ansonsten kannst du nur einen kompletten SATA-Kontroller durchreichen, keine einzelne SATA-Platte.

 

[ropf]

Ich hab mir gerade selbst einen Bock geschossen - die M.2-SSD (SanDisk SD8SN8U128G1001) ist eine SATA-Ausführung - hängt als /dev/sdb im device-tree - und damit vermutlich(!) am SATA-Controller.

Damit entfällt die Grundidee dieses Threads - dass das Gast-Windows den SATA-Controller quasi exlusiv nutzt - das Host-Linux hingegen die PCIe-Schnittstelle einer NVMe-SSD. Wenn beide Systeme jedoch um den SATA-Controller konkurrieren, lohnt der ganze Aufwand warscheinlich nicht.

Allerdings ist die Sache nicht ganz so einfach. Das Notebook (Thinkpad E570) unterstützt definitiv auch NVMe-SSDs. Um die Sache noch verwirrender zu machen - es soll M.2-Implementationen geben, die:

• direkt an PCIe hängen, aber (auch) einen SATA-Port für SATA-SSDs bieten
• an einem SATA-Port hängen, aber (auch) PCIe-Lanes für NVMe-SSDs bereitstellen
• ...

Hat jemand eine Idee, wie ich das für mein Gerät herausbekomme, ohne eine neue NVMe-SSD auf Verdacht zu kaufen?

 

[DenB]

M.2 und SATA sind Schnittstellen/Ports

AHCI (HDDs und erste SSDs) und NVME (SSDs) sind die Protokolle

Es gibt halt
SATA + AHCI (klassisch)
M.2 + AHCI ("Übergang")
M.2 + NVME ( "modern)

Von SATA + NVME weiß ich nichts.

 

[foofoobar]

Hat jemand eine Idee, wie ich das für mein Gerät herausbekomme, ohne eine neue NVMe-SSD auf Verdacht zu kaufen?

lspci -vt und die Hersteller Doku von der Kiste.