[SOLVED] Start VM: iothread is only valid with virtio disk or virtio-scsi-single controller, ignoring

[cmonty14]

Hallo,

ich erhalte diesen Fehler beim Start einer VM:
iothread is only valid with virtio disk or virtio-scsi-single controller, ignoring

Dies ist die zugehörige Konfiguration der VM:

agent: 1,fstrim_cloned_disks=1
balloon: 0
bios: ovmf
boot: order=scsi0;ide2
cores: 4
cpu: kvm64,flags=+aes
efidisk0: local_lvm-thin:vm-100-disk-1,size=4M
hostpci0: 0000:04:00.0
hostpci1: 0000:04:00.1
ide2: none,media=cdrom
machine: q35
memory: 4096
name: opnsense
net0: virtio=EE:C9:EC:DE:CC:DE,bridge=vmbr0,queues=8
net1: virtio=DE:C7:45:9A:2F:73,bridge=vmbr1,queues=8
numa: 0
onboot: 0
ostype: l26
scsi0: local_lvm-thin:vm-100-disk-0,iothread=1,size=8G
scsihw: virtio-scsi-pci
serial0: socket
smbios1: uuid=54afb3e4-1765-44b2-8623-9b8741ce4a67
sockets: 1
startup: order=1
tablet: 0
vmgenid: b5c14586-7e74-4e5e-96e0-aa076c39d3c7

Frage:
Was ist die Ursache dieses Fehlers?

THX

 

[fabian]

die message sagt es eigentlich eh - damit die 'iothread' option wirkung zeigt muss die disk entweder 'virtio' sein, oder an einem 'virtio-scsi-single' scsi controller haengen.. deine disk ist 'scsi' und haengt an einem 'virtio-scsi-pci' controller (bei '-single' kriegt jede disk einen eigenen controller)

 

[cmonty14]

Hallo Fabian,
vielen Dank für diese Erklärung.

Ich habe hierzu vier ergänzende Fragen:
1. Kann es sein, dass ich eine Disk des Typs "virtio" nicht erstellen kann, wenn diese Disk lvm-thin ist?
2. In welchen Szenarien ist es sinnvoll, einer virtuellen Disk eine eigenen Controller zuzuweisen?
3. Welche Voraussetzungen muss der Proxmox Server erfüllen?
4. Gibt es hierdurch einen (zusätzlichen) Overhead?

Danke

 

[fabian]

Hallo Fabian,
vielen Dank für diese Erklärung.

Ich habe hierzu vier ergänzende Fragen:
1. Kann es sein, dass ich eine Disk des Typs "virtio" nicht erstellen kann, wenn diese Disk lvm-thin ist?
2. In welchen Szenarien ist es sinnvoll, einer virtuellen Disk eine eigenen Controller zuzuweisen?
3. Welche Voraussetzungen muss der Proxmox Server erfüllen?
4. Gibt es hierdurch einen (zusätzlichen) Overhead?

Danke

1. virtio ist nicht der typ/das format der disk (bzw. des volumes, dass der VM als disk praesentiert wird), sondern die art wie diese(s) an die VM angebunden wird (so wie es bei einer physischen festplatte verschiedene bus systeme gibt - IDE, (S)ATA, SCSI, .., virtio ist ein spezieller "bus" fuer VMs der keine echte hardware emulieren muss, virtio-scsi ist ein spezieller SCSI controller der auch keiner echten hardware nachempfunden ist).
2. wenn du das letzte an performance rausholen willst in dem du iothreads aktivierst (aber achtung, je nach workload und hardware kann es auch langsamer sein -> mehr threads die um geteilte ressourcen konkurrieren koennen sich auch gegenseitig ausbremsen)
3. um virtio-scsi-single mit iothreads zu verwenden? keine besonderen. obs sinnvoll ist - s.h. 2./4.
4. jein. der Qemu prozess laeuft dann mit mehr threads. das kann ein mehr an performance bringen, aber heisst auch mehr scheduling overhead/contention

 

[cmonty14]

Hallo Fabian,
vielen Dank für die ausführlichen Antworten.

Ich entnehme den Antworten, dass die Nutzung von "IOthread" und eigenen Controllern eine Performance-Optimierung bringen kann.
Diese Optimierung bezieht sich dann aber auf das Disk IO der virtuellen Maschine.
Folglich könnte man sagen, dass es sinnvoll ist, dies zu nutzen, wenn die Anwendung auf der virtuellen Maschine ziemlich IO lastig ist.
Hier würde mir spontan einfallen:
eine OLTP Datenbank.

Sofern diese Theorie bis hierhin korrekt ist, dann stelle ich mir diese Frage:
Sollte man Win10 oder OPNsense/pfSense hier ebenfalls als IO lastig bewerten?

THX

 

[fabian]

opnsense/pfsense sollte nicht IO als bottle neck haben, bei windows 10 haengst natuerlich davon ab was dann tatsaechlich auf der kiste rennt. mit io thread an gibts du der VM quasi die chance, mehr read/write operationen auf die reise zu schicken. gerade bei SSD/NVME kann das ein mehr an performance bringen

 

[RolandK]

https://bugzilla.proxmox.com/show_bug.cgi?id=3890