slacky.eu

Ciao a tutti!
Ho creato un'installazione di win10 in virt-manager per fare alcune prove.

Problema, il sistema è pressoché inutilizzabile, e anche snervante. Davvero troppo lento anche ad aprire notepad per capirci..
M'è venuto il dubbio che potrei aver impostato non al meglio la configurazione della CPU in virt-manager. E altre cose forse.

Queste le caratteristiche dell'host. Ok, non ridete...

Codice: Seleziona tutto

Intel(R) Core(TM)2 Duo CPU     E8200  @ 2.66GHz
RAM: 4GB

Alla macchina virtuale ho assegnato 1.9 GB, un po' meno della metà.
Per quanto riguarda la cpu:

Codice: Seleziona tutto

CPU host logico: 2
- allocazione corrente 2
- allocazione massima 2

Configurazione: "copia  configurazione  cpu host"

Topologia
- socket 1
- core 2
- thread 1

Ho due dubbi, dopo alcune ricerche in rete:

1. Come dovrei impostare la CPU alla voce configurazione?
Ho letto che settare "copia configurazione cpu host" sarebbe errato e si dovrebbe invece impostare dalla tendina "Model" a "host-passthrough". Purtroppissimo quella voce non è tra le scelte disponibili.

2. La topologia vi pare giusta per la mia CPU? Il core 2 duo dell'host ha: 2 core fisici, e ciascuno è in grado di gestire 1 solo thread. Ovviamente il socket è uno solo.

Se poteste darmi una conferma...
L'obiettivo è quello di ottenere un sistema Guest win10, per quanto possibile maggiormente prestante, o comunque impostato al massimo di quanto può dare l'hardware pur vetusto in oggetto.

Grazie in anticipo!

Mi rispondo da solo in parte. Anche se una conferma da parte vostra mi farebbe comodo.
A quanto pare in questo link davano qualche suggerimento in merito:

https://www.reddit.com/r/VFIO/comments/ ... nager_cpu/

Con alcune ricerche in più ho determinato quali "domain" (macchine virtuali, sistemi guests, chiamateli come volete) sono in gestione da parte di libvirt:

Codice: Seleziona tutto

# virsh list --all
 Id    Nome                           Stato
----------------------------------------------------
 8     win-10-pro-disk                in esecuzione
 -     memtest86                      terminato
 -     ubuntu                         terminato

A questo punto a me interessava il primo chiamato "win-10-pro-disk".
Dopodiché vado ad editare il file di configurazione corrispondente usando

Codice: Seleziona tutto

virsh edit win-10-pro-disk

Ed ecco che al tag <cpu> imposto il parametro "mode=" a "host-passthrough":

Codice: Seleziona tutto

<cpu mode='host-passthrough' check='none'>
    <topology sockets='1' cores='2' threads='1'/>
</cpu>

Anche la topologia è lì dentro...
Ad ogni modo quella si può impostare anche dall'interfaccia di virt-manager.

Ecco, aprendo virt-manager e riavviando il sistema guest, andando in visualizza > dettagli si legge:

Configurazione
Modello host-passthrough.

Il resto è come prima:
Cpu host logico: 2
Allocazione corrente 2
Allocazione massima 2

Topologia
imposta manualmente
socket 1
core 2
thread 1

Risultato:
Avviato così il sistema guest, risulta utilizzabile per le poche prove che ci volevo fare.
Seppure resta ben distante dalle prestazioni di un sistema installato direttamente sull'hardware, è molto molto più reattivo rispetto alle impostazioni di prima.

Credo che si possano migliorare anche altri aspetti.
Avevo installato i driver VirtIO e impostato il disco di sistema appunto su bus virtio anziché SATA. Anche quello un pochino aveva migliorato.

A questo punto potrebbe essere ancora migliorabile la reattività del guest cercando di ottimizzare ad esempio gestione della grafica?
Magari anche lì sfruttando qualche sorta di passthrough in modo da far gestire direttamente alla scheda video dell'host la grafica del guest?

Domanda da ignorantone...

Ciao joe,

partirei con una domanda: il tuo processore dovrebbe supportare l'accelerazione hardware alla virtualizzazione Intel (Intel VT-x), almeno secondo le specifiche Intel. Hai provato ad abilitare l'accelerazione KVM del kernel host caricando il modulo "kvm-intel" prima di far partire il guest, al di là del passthrough della CPU?
Per gli altri aspetti:

concordo per i dischi in virtio, qualcosa dovrebbero accelerare rispetto alle altre opzioni
il GPU passthrough è possibile a patto di avere un chipset sulla scheda madre con supporto alla virtualizzazione delle periferiche (Intel VT-d nel tuo caso, probabilmente), oltre ad una GPU aggiuntiva da dedicare esclusivamente al guest

Grazie per la risposta anzitutto.

Anticipo che nonostante con quell'impostazione del cpu passthrough qualche miglioramento l'ho notato, direi che ancora non ci siamo, win 10 resta ancora più che inutilizzabile. La lentezza snervante compromette la possibilità anche di fare semplici prove.

Venendo al tecnico.
KVM, nella fattispecie il mdulo kvm_intel, in qualche modo viene caricato automaticamente. E la cosa strana è che lo vedo lì anche ora che non ho neanche avviato libvirt né virt-manager.

Codice: Seleziona tutto

$ lsmod |grep kvm
kvm_intel             290816  0
kvm                   909312  1 kvm_intel
irqbypass              16384  1 kvm

Vedi?
Ora se rilancio lsmod dopo aver avviato libvirt, poi virt-manager, e infine lanciato la macchina virtuale di win10, ecco cosa appare:

Codice: Seleziona tutto

$ lsmod |grep kvm
kvm_intel             290816  4
kvm                   909312  1 kvm_intel
irqbypass              16384  3 kvm

Per rispondere alla tua domanda quindi, sì: kvm_intel sembrerebbe caricato e al lavoro... (nonostante non lo abbia caricato io a mano, questo non so spiegarmelo ma va bé).

Veniamo alla GPU dedicata, no capirai bene che un ferro vecchio del genere... la scheda video in uso è una silent Nvidia GeForce 210 della Asus.
La scheda madre è una umilissima asus p5n-mx.

https://www.asus.com/us/Motherboards/P5 ... fications/

A dirla tutta sai che avrebbe anche un chipset grafico integrato della nvidia?
L'avevo escluso dall'utilizzo quando avevo preso un nuovo monitor che non ha ingresso VGA, insieme al monitor avevo preso anche la scheda video dedicata con uscita HDMI.

Ma effettivamente una GPU disoccupata su quella scheda madre c'è.
Il problema è che mancherà senz'altro l'altro requisito, non credo ci sia VT-d a livello di scheda madre.

Invece confermo che la CPU comprende la funzionalità VT-x (dovrebbe essere il flag vmx in cpuinfo...):

Codice: Seleziona tutto

#  grep --color vmx /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 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm
vmx flags       : vnmi flexpriority tsc_offset vtpr vapic

Ho provato anche l'installazione di ubuntu, con tutti i crismi quindi Gnome ecc ecc, ma risulta abbastanza fluido quando si apre un programma non pesante ecc ecc... Su win10 invece, anche solo aprire il menù "start" o esplora risorse è una pena!

Se da quanto ho scritto hai qualche altro consiglio... Al di là di tutto potrebbe tornare sempre utile capire qual è il problema e se ci sia modo di migliorare la situazione anche su questo hardware.

PS.
Già qualche tempo fa avevo armeggiato con virt-manager per far qualche prova relativa al UEFI (OVMF). Poi l'altro giorno mi chiede un amico cosa potrebbe usare per scaricare video da youtube, e siccome youtube-dl non fa al caso suo per via della linea di comando che non sa/vuole usare nè cosa sia, mi ero detto: perché non provare qualche tool per win per lo scopo... E l'unica installazione win che avevo aportata di mano era quel sistema lì in VM. Pessima idea!

EDIT
Ho trovato anche questo comando per ulteriore conferma:

Codice: Seleziona tutto

~# virt-host-validate
  QEMU: Checking for hardware virtualization                                 : PASS
  QEMU: Checking if device /dev/kvm exists                                   : PASS
  QEMU: Checking if device /dev/kvm is accessible                            : PASS
  QEMU: Checking if device /dev/vhost-net exists                             : PASS
  QEMU: Checking if device /dev/net/tun exists                               : PASS
  QEMU: Checking for cgroup 'memory' controller support                      : PASS
  QEMU: Checking for cgroup 'memory' controller mount-point                  : PASS
  QEMU: Checking for cgroup 'cpu' controller support                         : PASS
  QEMU: Checking for cgroup 'cpu' controller mount-point                     : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support                     : PASS
  QEMU: Checking for cgroup 'cpuacct' controller mount-point                 : PASS
  QEMU: Checking for cgroup 'cpuset' controller support                      : PASS
  QEMU: Checking for cgroup 'cpuset' controller mount-point                  : PASS
  QEMU: Checking for cgroup 'devices' controller support                     : PASS
  QEMU: Checking for cgroup 'devices' controller mount-point                 : PASS
  QEMU: Checking for cgroup 'blkio' controller support                       : PASS
  QEMU: Checking for cgroup 'blkio' controller mount-point                   : PASS
  QEMU: Checking for device assignment IOMMU support                         : WARN (No ACPI DMAR table found, IOMMU either disabled in BIOS or not supported by this hardware platform)
   LXC: Checking per Linux >= 2.6.26                                         : PASS
   LXC: Checking for namespace ipc                                           : PASS
   LXC: Checking for namespace mnt                                           : PASS
   LXC: Checking for namespace pid                                           : PASS
   LXC: Checking for namespace uts                                           : PASS
   LXC: Checking for namespace net                                           : PASS
   LXC: Checking for namespace user                                          : PASS
   LXC: Checking for cgroup 'memory' controller support                      : PASS
   LXC: Checking for cgroup 'memory' controller mount-point                  : PASS
   LXC: Checking for cgroup 'cpu' controller support                         : PASS
   LXC: Checking for cgroup 'cpu' controller mount-point                     : PASS
   LXC: Checking for cgroup 'cpuacct' controller support                     : PASS
   LXC: Checking for cgroup 'cpuacct' controller mount-point                 : PASS
   LXC: Checking for cgroup 'cpuset' controller support                      : PASS
   LXC: Checking for cgroup 'cpuset' controller mount-point                  : PASS
   LXC: Checking for cgroup 'devices' controller support                     : PASS
   LXC: Checking for cgroup 'devices' controller mount-point                 : PASS
   LXC: Checking for cgroup 'blkio' controller support                       : PASS
   LXC: Checking for cgroup 'blkio' controller mount-point                   : PASS
   LXC: Checking if device /sys/fs/fuse/connections exists                   : PASS

joe ha scritto: ↑
gio 18 feb 2021, 20:38
Grazie per la risposta anzitutto.

Anticipo che nonostante con quell'impostazione del cpu passthrough qualche miglioramento l'ho notato, direi che ancora non ci siamo, win 10 resta ancora più che inutilizzabile. La lentezza snervante compromette la possibilità anche di fare semplici prove.

Io di solito in queste situazioni faccio una veloce prova con qemu-kvm direttamente per testare quanto l'accelerazione kvm aiuti.
Una prova del tipo:

Codice: Seleziona tutto

qemu-system-x86_64 -m 2g -enable-kvm  -hda disk.qcow2 -boot c

dovrebbe mostrarti al volo se, con kvm esplicitamente abilitato, la situazione sia differente o meno rispetto a quanto osservato da libvirt/virt-manager.

joe ha scritto: ↑
gio 18 feb 2021, 20:38
Venendo al tecnico.
KVM, nella fattispecie il mdulo kvm_intel, in qualche modo viene caricato automaticamente. E la cosa strana è che lo vedo lì anche ora che non ho neanche avviato libvirt né virt-manager.
Codice: Seleziona tutto
$ lsmod |grep kvm
kvm_intel             290816  0
kvm                   909312  1 kvm_intel
irqbypass              16384  1 kvm
Vedi?
Ora se rilancio lsmod dopo aver avviato libvirt, poi virt-manager, e infine lanciato la macchina virtuale di win10, ecco cosa appare:
Codice: Seleziona tutto
$ lsmod |grep kvm
kvm_intel             290816  4
kvm                   909312  1 kvm_intel
irqbypass              16384  3 kvm
Per rispondere alla tua domanda quindi, sì: kvm_intel sembrerebbe caricato e al lavoro... (nonostante non lo abbia caricato io a mano, questo non so spiegarmelo ma va bé).

Anche io ce l'ho in caricamento automatico all'avvio, senza override specifici in /etc/rc.d/rc.modules-$(uname -r) o /etc/rc.d/rc.modules.local.
Forse c'è lo zampino di udev in tutto questo, ma non ne sono sicuro.

joe ha scritto: ↑
gio 18 feb 2021, 20:38
Veniamo alla GPU dedicata, no capirai bene che un ferro vecchio del genere... la scheda video in uso è una silent Nvidia GeForce 210 della Asus.
La scheda madre è una umilissima asus p5n-mx.

https://www.asus.com/us/Motherboards/P5 ... fications/

A dirla tutta sai che avrebbe anche un chipset grafico integrato della nvidia?
L'avevo escluso dall'utilizzo quando avevo preso un nuovo monitor che non ha ingresso VGA, insieme al monitor avevo preso anche la scheda video dedicata con uscita HDMI.

Ma effettivamente una GPU disoccupata su quella scheda madre c'è.
Il problema è che mancherà senz'altro l'altro requisito, non credo ci sia VT-d a livello di scheda madre.

Invece confermo che la CPU comprende la funzionalità VT-x (dovrebbe essere il flag vmx in cpuinfo...):
Codice: Seleziona tutto
#  grep --color vmx /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 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm
vmx flags       : vnmi flexpriority tsc_offset vtpr vapic
Codice: Seleziona tutto
~# virt-host-validate
...
  QEMU: Checking for device assignment IOMMU support                         : WARN (No ACPI DMAR table found, IOMMU either disabled in BIOS or not supported by this hardware platform)

Dovresti trovare il modo di abilitare il IOMMU nel BIOS della scheda madre. A quel punto potresti essere in grado di fare il GPU passthrough della scheda video più scadente.

joe ha scritto: ↑
gio 18 feb 2021, 20:38
PS.
Già qualche tempo fa avevo armeggiato con virt-manager per far qualche prova relativa al UEFI (OVMF). Poi l'altro giorno mi chiede un amico cosa potrebbe usare per scaricare video da youtube, e siccome youtube-dl non fa al caso suo per via della linea di comando che non sa/vuole usare nè cosa sia, mi ero detto: perché non provare qualche tool per win per lo scopo... E l'unica installazione win che avevo aportata di mano era quel sistema lì in VM. Pessima idea!

C'è una GUI minimale per youtube-dl: youtube-dl-gui.

Parto a risponderti dal fondo.

La funzionalità IOMMU, aka "VT-d" non credo che sia supportata dalla mia scheda madre. È roba troppo vetusta mi sa tanto. Il processore supporta VT-x, ma che la scheda supporti VT-d ne dubito...
Non so neanche come verificarlo di preciso, da come ho letto si dovrebbe avere un'idea da "dmesg |grep DARM". Ma se la funzionalità non è attivata a livello BIOS sarebbe normale non ottenere nulla in output. In effetti a me non ritorna niente. Per cui il VT-d non è abilitato.
Se sia effettivamente supportato dalla mia scheda madre non l'ho capito.
Però a livello di processore il vt-d non risulta:
https://ark.intel.com/content/www/it/it ... z-fsb.html

Nella sezione tecnologia avanzate c'è solo VT-x:

Codice: Seleziona tutto

Intel® Virtualization Technology ‡ Sì

Facendo un confronto con un processore moderno ecco che si legge anche altro:
https://ark.intel.com/content/www/it/it ... -0ghz.html

Codice: Seleziona tutto

Intel® Virtualization Technology ‡ Sì
Intel® Virtualization Technology for Directed I/O ‡ Sì
Intel® VT-x con Extended Page Tables (EPT) ‡ Sì

Di cui la seconda voce dovrebbe essere quella relativa a VT-d:

Intel® Virtualization Technology for Directed I/O (VT-d) aggiunge all'attuale supporto della virtualizzazione per le piattaforme IA-32 (VT-x) e Itanium® (VT-i) il supporto per la virtualizzazione dei dispositivi di I/O. Intel VT-d consente agli utenti di migliorare la sicurezza e l'affidabilità dei sistemi e di aumentare le prestazioni dei dispositivi di I/O negli ambienti virtualizzati.

In soldoni nel mio caso niente VT-d, già a livello di CPU, per cui è inutile verificare la scheda madre: tutti i dispositivi devono supportare quella funzionalità (cpu, mb, bios) per poterla utilizzare in concreto.

La prova diretta con qemu-system-ecc-ecc, non mi riesce per via dell'emulazione UEFI che complica un po' le cose.

Però avviando virt-manger e la macchina virtuale con win10, attraverso pgrep posso facilmente capire come viene lanciato il comando "RAW". Lo metto qua sotto, occhio che è tutto su una riga (giustamente dopotutto):

Codice: Seleziona tutto

$ pgrep -a qemu |grep --color kvm
2883 /usr/bin/qemu-kvm -name guest=win-10-pro-disk,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-win-10-pro-disk/master-key.aes -machine pc-q35-4.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host -drive file=/usr/share/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win-10-pro-disk_VARS.fd,if=pflash,format=raw,unit=1 -m 1900 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid 6c8e1e82-a089-4e56-ac24-6dd2baa716fa -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=23,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot menu=off,strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-pci-bridge,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x11,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x4 -device pcie-root-port,port=0x15,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x5 -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive file=/var/lib/libvirt/images/win-10-pro-disk-1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.5,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/libvirt/images/win-10-pro-disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.7,addr=0x0,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=2 -drive file=/home/joe/temp/partizionamento-virtuale/Win10_Pro_20H2_v2_Italian_x64.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -drive file=/home/joe/Downloads/virtio-win-0.1.185.iso,format=raw,if=none,id=drive-sata0-0-2,media=cdrom,readonly=on -device ide-cd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:22:30:70,bus=pci.6,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -sandbox off -messaggio timestamp=on

A scanso di equivoci l'eseguibile che usa virt-manager/libvirt per lanciare qemu è qemu-kvm, ma in realtà si tratta di un link simbolico che punta al solito qemu- system-x86_64, quello che indicavi anche tu insomma..

Codice: Seleziona tutto

$ file `which qemu-kvm`
/usr/bin/qemu-kvm: symbolic link to qemu-system-x86_64

Il punto di interesse per capire se l'accelerazione hardware della virtualizzazione è sfruttata dovrebbe essere riportata dall'opzionie "-machine" e dal suo attributo "accel=", nel mio caso si legge "-machine accel=kvm".

Quindi lato kvm / kvm_intel dovremmo esserci. Almeno credo...
Metto anche un link ad una domanda simile con risposta che ho trovato:

https://superuser.com/questions/1317011 ... ot-working

L'unica cosa che mi lascia ancora qualche dubbio è proprio il settaggio cpu host-passthrough, mi sembra molto strano che virt-manager non abbia di suo un'opzione di scelta bene in vista per attivare quella funzionalità così importante e che ci si debba inventare la configuarzione a mano di libvirt per ottenere quella configurazione.

joe ha scritto: ↑
ven 19 feb 2021, 13:53
il settaggio cpu host-passthrough, mi sembra molto strano che virt-manager non abbia di suo un'opzione di scelta bene in vista

Ce l'ha, la vedi nel menu a tendina della scelta manuale della cpu, ma non è quello che il nome potrebbe far intendere.
Nella documentazione trovi quello che c'è da sapere.

Qui possiamo dire che non ha nulla a che fare con l'utilizzo "diretto" della cpu dell'host, e che una macchina virtuale impostata in quel modo crea problemi quando la "porti" su un hardware differente. Per questo motivo libvirt preferisce l'opzione 'host-model' quando scegli di copiare la configurazione cpu dell'host.

Per il resto, il problema di win10 è l'utilizzo abnorme del disco che "pesa" sulla ram disponibile, a prescindere da quanta ne riservi per la VM.
In un sistema con 8 GB di ram, dedicandone 4 al guest, il sistema host swappa su disco non appena arrivi alla schermata del desktop.
Fai un po tu...

Metti WIN7-32Bit e risolvi il problema, almeno fino a quando MS continuerà il supporto a pagamento.

Nel menù a tendina con i vari modelli delle cpu, host-passthorugh non è presente.
Lo rilevano anche qui:
https://www.reddit.com/r/VFIO/comments/ ... nager_cpu/

Posso mettere la spunta alla casella "copia configurazione CPU host" al massimo, ma non è la stessa cosa da quanto ho letto: copiando la configurazione host, semplicemente dovrebbe simulare il comportamento del modello di cpu che monta l'host. Ma si tratterebbe sempre di un'emulazione software.

Invece il concetto di host-passthrough dovrebbe essere: usa direttamente la CPU vera "hardware" dell'host senza emularla in software.

Oppure ho capito male io il funzionamento, da come scrivi ne ho il sospetto.

Insomma, alla fine, in pratica qual è la configrazione preferibile di quel parametro "cpu model" al fine di massimizzare le prestazioni?
A me interessa questo per il momento.
Della portabilità della VM non m'importa, ci faccio solo delle prove estemporanee.

Per quanto riguarda win10 il mio obiettivo era proprio fare qualche prova su quel sistema. Anche perché a dirla tutta lo conosco poco alla fine.
Detto questo anche io ho notato la lentezza solo con win10, come ho detto ubuntu con gnome fila via liscio e allegro.
Posso provare anche win7 tanto per riprova questo sì.

joe ha scritto: ↑
dom 21 feb 2021, 22:12
Nel menù a tendina con i vari modelli delle cpu, host-passthorugh non è presente.

Probabilmente dipende dalla versione di virt-manager|qemu e/o dalla cpu dell'host.

Per la faccenda cpu/topologia: https://libvirt.org/formatdomain.html#c ... d-topology

Le prestazioni migliori le ottieni più la cpu "esposta" verso il guest si avvicina a quella che hai fisicamente nell'hardware.

Quindi host-model dovrebbe essere più che sufficiente.

Su WIN10 non torno, se non per dire di lasciar perdere con quell'hardware. Forse, e dico forse, potresti avere dei benefici con la versione a 32-bit, ma non ci metterei la mano sul fuoco.

Puoi provare a raddoppiare il valore "vgamem" della scheda video QXL

Codice: Seleziona tutto

 <model type="qxl" ram="65536" vram="65536" vgamem="16384" heads="1" primary="yes"/>

ma secondo me il problema, come già detto, non è lì.

Ok, ho provato a lanciare con le impostazioni indicate, riporto per completezza le opzioni con cui viene richiamato l'eseguibile "qemu":

Codice: Seleziona tutto

pgrep -a kvm|grep --color cpu
32226 /usr/bin/qemu-kvm -name guest=win-10-pro-disk,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-win-10-pro-disk/master-key.aes -machine pc-q35-4.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Penryn,vme=on,vmx=on,pdcm=on,x2apic=on,tsc-deadline=on,hypervisor=on,arat=on,tsc_adjust=on,pdpe1gb=on -drive file=/usr/share/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win-10-pro-disk_VARS.fd,if=pflash,format=raw,unit=1 -m 1900 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid 6c8e1e82-a089-4e56-ac24-6dd2baa716fa -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=23,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot menu=off,strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-pci-bridge,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x11,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x4 -device pcie-root-port,port=0x15,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x5 -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive file=/var/lib/libvirt/images/win-10-pro-disk-1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.5,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/libvirt/images/win-10-pro-disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.7,addr=0x0,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=2 -drive file=/home/joe/temp/partizionamento-virtuale/Win10_Pro_20H2_v2_Italian_x64.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on -device
ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -drive file=/home/joe/Downloads/virtio-win-0.1.185.iso,format=raw,if=none,id=drive-sata0-0-2,media=cdrom,readonly=on -device ide-cd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:22:30:70,bus=pci.6,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=32,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -sandbox off -messaggio timestamp=on

In particolare l'opzione -cpu così risulta:

Codice: Seleziona tutto

-cpu Penryn,vme=on,vmx=on,pdcm=on,x2apic=on,tsc-deadline=on,hypervisor=on,arat=on,tsc_adjust=on,pdpe1gb=on

Anche nella tendina di modelli cpu, appare "Penryn".
Però in realtà il processore dell'host sarebbe della serie "Wolfdale"... (Core 2 Duo E8200 2.66 GHz)
https://ark.intel.com/content/www/us/en ... fdale.html
https://ark.intel.com/content/www/us/en ... enryn.html

Per verifica:

Codice: Seleziona tutto

<domain type='kvm'>
  <name>win-10-pro-disk</name>
  <uuid>6c8e1e82-a089-4e56-ac24-6dd2baa716fa</uuid>
  <memory unit='KiB'>1945600</memory>
  <currentMemory unit='KiB'>1945600</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-4.1'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/win-10-pro-disk_VARS.fd</nvram>
    <bootmenu enable='no'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='none'>
    <model fallback='allow'/>
    <topology sockets='1' cores='2' threads='1'/>
  </cpu>

Codice: Seleziona tutto

    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='32768' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>

Stando così le cose, siamo sicuri che sia la configurazione migliore possibile per massimizzare le prestazioni?
(fermo restando le limitazioni hardware che quelle sono e quelle restano...).

joe ha scritto: ↑
lun 22 feb 2021, 17:50
Anche nella tendina di modelli cpu, appare "Penryn".
Però in realtà il processore dell'host sarebbe della serie "Wolfdale"... (Core 2 Duo E8200 2.66 GHz)

È corretto. Libvirt, con l'opzione host-model, ha rilevato il processore più "vicino" al tuo e "raccomandato" per gli host Intel x86.

Con host-passthrough puoi "forzare" la virtualizzazione di un processore identico al tuo, con l'avvertenza che le caratteristiche non supportate verranno filtrate(quindi non dovrebbero esserci grandi differenze).
I log dovrebbero darti indicazioni precise su cosa viene eventualmente "scartato".

Altre possibili ottimizzazioni? Non ne ho la minima idea.

Ti ringrazio per le risposte.
Prenderò in considerazione il consiglio di mettere win7. Per provare applicazioni in ambiente winz dovrebbe bastare. se mi servirà win10 posso sempre installarlo "bare metal" o anche fare un bel aggiornamento hardware che sarebbe anche ora (anche se ho sentito che al momento i prezzi sono particolarmente lievitati, per cui forse meglio aspettare ancora un po').

Se vuoi rimanere su win10, c'è il progetto ameliorated, che fornisce una versione alleggerita da spyware e altra roba di windows 10.
Su quella macchina comunque, come diceva rik70, non mi aspetterei miracoli...

Grazie posso fare una prova anche con quella soluzione.
Tra l'altro info utile anche in generale se si vuole arginare un po' l'invadenza de MS.

slacky.eu

CPU host-passthrough impostazione ottimale virt-manager

CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager

Re: CPU host-passthrough impostazione ottimale virt-manager