Prestazioni del disco KVM incredibilmente basse (file del disco qcow2 + virtio)

Sto riscontrando seri problemi di prestazioni del disco durante l'impostazione di un guest KVM. Utilizzando un semplice ddtest, la partizione sull'host su cui risiedono le immagini qcow2 (un array RAID con mirroring) scrive a oltre 120 MB / s , mentre il mio guest riceve scritture che vanno da 0,5 a 3 MB / s .

• Il guest è configurato con un paio di CPU e 4G di RAM e al momento non esegue nient'altro; è un'installazione completamente minimale al momento.
• Le prestazioni sono testate utilizzando time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
• L'ospite è configurato per usare virtio, ma questo non sembra fare la differenza per le prestazioni.
• Le partizioni host sono allineate a 4kb (e le prestazioni vanno comunque bene sull'host).
• L'uso della cache di writeback sui dischi aumenta in modo massiccio le prestazioni riportate, ma preferirei non utilizzarle; anche senza di essa le prestazioni dovrebbero essere molto migliori di così.
• L'host e il guest eseguono entrambi Ubuntu 12.04 LTS, fornito con qemu-kvm 1.0 + noroms-0ubuntu13 e libvirt 0.9.8-2ubuntu17.1.
• L'host ha la scadenza IO scheduler abilitata e il guest ha noop.

Sembra che ci siano molte guide là fuori che ottimizzano le prestazioni di kvm, e alla fine ci arriverò, ma sembra che dovrei ottenere prestazioni notevolmente migliori di questa in questo momento, quindi sembra che qualcosa sia già molto sbagliato.

Aggiornamento 1

E improvvisamente quando torno indietro e collaudo ora, sono 26,6 MB / s; questo è più simile a quello che mi aspettavo w / qcrow2. Lascerò la domanda nel caso in cui qualcuno abbia qualche idea su quale potrebbe essere stato il problema (e nel caso in cui ritorni misteriosamente di nuovo).

Aggiornamento 2

Ho smesso di preoccuparmi delle prestazioni di qcow2 e sono passato a LVM sopra RAID1 con immagini grezze, usando ancora virtio ma impostando cache = 'none' e io = 'native' sull'unità disco. La performance di scrittura ora è appx. 135 MB / s utilizzano lo stesso test di base di cui sopra, quindi non sembra avere molto senso capire quale fosse il problema quando può essere facilmente risolto completamente.

Bene, sì, i file qcow2 non sono progettati per prestazioni incredibilmente veloci. Otterrai una fortuna molto migliore dalle partizioni grezze (o, preferibilmente, LV).

Come ottenere le massime prestazioni con QCOW2 :

qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ

Il più importante è la preallocazione che dà una bella spinta, secondo gli sviluppatori di qcow2. Adesso è quasi alla pari con LVM ! Nota che questo è di solito abilitato nelle moderne distribuzioni Linux (Fedora 25+).

Inoltre puoi fornire cache non sicura se questa non è un'istanza di produzione (è pericolosa e sconsigliata, valida solo per i test):

<driver name='qemu' cache='unsafe' />

Alcuni utenti segnalano che questa configurazione supera la configurazione LVM / non sicura in alcuni test.

Per tutti questi parametri è richiesto l' ultimo QEMU 1.5+ ! Ancora una volta, la maggior parte delle distro moderne ha queste.

Ho ottenuto ottimi risultati per l'immagine qcow2 con questa impostazione:

<driver name='qemu' type='raw' cache='none' io='native'/>

che disabilita le cache degli ospiti e abilita AIO (Asincrono IO). L'esecuzione del ddcomando mi ha dato 177 MB / s sull'host e 155 MB / s sul guest. L'immagine viene posizionata sullo stesso volume LVM in cui è stato eseguito il test dell'host.

La mia qemu-kvmversione è 1.0+noroms-0ubuntu14.8e kernel 3.2.0-41-genericdallo stock Ubuntu 12.04.2 LTS.

Se stai eseguendo il tuo vms con un singolo comando, per argomenti che puoi usare

kvm -drive file = / path_to.qcow2, if = virtio, cache = off <...>

Mi ha portato da 3 MB / sa 70 MB / s

Nelle vecchie versioni di Qemu / KVM, il backend Qcow2 era molto lento quando non era preallocato, tanto più se usato senza cache di writeback abilitata. Vedi qui per maggiori informazioni.

Nelle versioni più recenti di Qemu, i file Qcow2 sono molto più veloci, anche quando non si utilizza la preallocazione (o preallocazione solo per i metadati). Tuttavia, i volumi LVM rimangono più veloci.

Una nota sulle modalità cache: la cache writeback è la modalità preferita, a meno che non si usi un guest senza supporto disabilitato o disabilitato per lo svuotamento / le barriere della cache del disco. In pratica, i guest Win2000 + e le eventuali opzioni di montaggio su barriera Linux EXT4, XFS o EXT3 + sono multe. D'altra parte, cache = unsafe non dovrebbe mai essere usato dalle macchine di produzione, poiché i flush della cache non vengono propagati al sistema host. Un arresto imprevisto dell'host può letteralmente distruggere il filesystem del guest.

Ho riscontrato esattamente lo stesso problema. All'interno della macchina virtuale RHEL7 ho un software di destinazione iSCSI LIO a cui si collegano altre macchine. Come memoria sottostante (backstore) per i miei LUN iSCSI inizialmente ho usato LVM, ma poi sono passato a immagini basate su file.

Per farla breve: quando il backup dell'archiviazione è collegato al controller di archiviazione virtio_blk (vda, vdb, ecc.) - le prestazioni del client iSCSI connesso alla destinazione iSCSI erano nel mio ambiente ~ 20 IOPS, con throughput (in base alla dimensione IO) ~ 2- 3 MiB / s. Ho cambiato il controller del disco virtuale all'interno della macchina virtuale in SCSI e sono in grado di ottenere 1000+ IOPS e throughput 100+ MiB / s dai miei client iSCSI.

<disk type='file' device='disk'>
   <driver name='qemu' type='qcow2' cache='none' io='native'/>
   <source file='/var/lib/libvirt/images/station1/station1-iscsi1-lun.img'/>
   <target dev='sda' bus='scsi'/>
   <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>