Desempenho de disco KVM incrivelmente baixo (arquivos de disco qcow2 + virtio)

Estou tendo alguns problemas sérios de desempenho do disco ao configurar um convidado KVM. Usando um ddteste simples , a partição no host em que as imagens qcow2 residem (uma matriz RAID espelhada) grava em mais de 120 MB / s , enquanto meu convidado recebe gravações que variam de 0,5 a 3 MB / s .

• O convidado está configurado com algumas CPUs e 4G de RAM e atualmente não está executando mais nada; é uma instalação completamente mínima no momento.
• O desempenho é testado usando time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
• O convidado está configurado para usar o virtio, mas isso não parece fazer diferença no desempenho.
• As partições do host estão alinhadas em 4kb (e o desempenho é bom no host, pelo menos).
• O uso do cache de write-back nos discos aumenta enormemente o desempenho relatado, mas prefiro não usá-lo; mesmo sem ele, o desempenho deve ser muito melhor que isso.
• O host e o convidado estão executando o Ubuntu 12.04 LTS, que vem com o qemu-kvm 1.0 + noroms-0ubuntu13 e libvirt 0.9.8-2ubuntu17.1.
• O host tem o agendador de E / S do prazo ativado e o convidado não tem oop.

Parece haver muitos guias por aí ajustando o desempenho do kvm, e chegarei lá eventualmente, mas parece que eu deveria estar obtendo um desempenho muito melhor do que esse neste momento, então parece que algo já está muito errado.

Atualização 1

E de repente, quando volto e testo agora, é 26,6 MB / s; isso é mais parecido com o que eu esperava com o qcrow2. Deixarei a questão em aberto, caso alguém tenha alguma idéia do que poderia ter sido o problema (e no caso de ele voltar misteriosamente novamente).

Atualização 2

Parei de me preocupar com o desempenho do qcow2 e passei para o LVM em cima do RAID1 com imagens brutas, ainda usando o virtio, mas configurando cache = 'none' e io = 'native' na unidade de disco. O desempenho de gravação agora é appx. 135 MB / s usando o mesmo teste básico acima, portanto, não parece haver muito sentido em descobrir qual era o problema quando ele pode ser tão facilmente resolvido por completo.

Bem, sim, os arquivos qcow2 não foram projetados para um desempenho incrivelmente rápido. Você terá muito mais sorte com partições brutas (ou, preferencialmente, LVs).

Como obter o melhor desempenho com o QCOW2 :

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

O mais importante é a pré-localização, o que dá um bom impulso, de acordo com os desenvolvedores do qcow2. Está quase no mesmo nível do LVM agora! Observe que isso geralmente é ativado nas distribuições modernas do Linux (Fedora 25+).

Além disso, você pode fornecer cache não seguro se essa não for uma instância de produção (isso é perigoso e não recomendado, apenas bom para teste):

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

Alguns usuários relatam que essa configuração supera a configuração LVM / não segura em alguns testes.

Para todos esses parâmetros, é necessário o mais recente QEMU 1.5+ ! Novamente, a maioria das distribuições modernas tem essas.

Consegui ótimos resultados para a imagem qcow2 com esta configuração:

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

que desativa os caches de convidados e habilita o AIO (E / S assíncrona). Executar seu ddcomando me deu 177MB / s no host e 155MB / s no convidado. A imagem é colocada no mesmo volume LVM em que o teste do host foi realizado.

Minha qemu-kvmversão é 1.0+noroms-0ubuntu14.8e kernel 3.2.0-41-genericdo estoque Ubuntu 12.04.2 LTS.

Se você estiver executando seus vms com um único comando, para argumentos, você pode usar

kvm -drive arquivo = / caminho_para.qcow2, se = virtio, cache = desativado <...>

Me passou de 3MB / s para 70MB / s

Nas versões antigas do Qemu / KVM, o back-end do Qcow2 era muito lento quando não pré-alocado, mais ainda se usado sem o cache de write-back ativado. Veja aqui para mais informações.

Nas versões mais recentes do Qemu, os arquivos Qcow2 são muito mais rápidos, mesmo quando não há pré-alocação (ou pré-alocação apenas de metadados). Ainda assim, os volumes LVM permanecem mais rápidos.

Uma observação sobre os modos de cache: o cache de write - back é o modo preferido, a menos que seja utilizado um convidado com ou sem suporte desabilitado para liberação / barreiras do cache de disco. Na prática, os convidados Win2000 + e qualquer opção de montagem de barreira Linux EXT4, XFS ou EXT3 + são multas. Por outro lado, cache = inseguro nunca deve ser usado em máquinas de produção, pois as liberações de cache não são propagadas para o sistema host. Um desligamento inesperado do host pode literalmente destruir o sistema de arquivos do hóspede.

Eu experimentei exatamente o mesmo problema. Na máquina virtual RHEL7, tenho o software de destino LIO iSCSI ao qual outras máquinas se conectam. Como armazenamento subjacente (backstore) para minhas LUNs iSCSI, usei inicialmente o LVM, mas depois mudei para imagens baseadas em arquivo.

Longa história: quando o backup de armazenamento é anexado ao controlador de armazenamento virtio_blk (vda, vdb, etc.) - o desempenho do cliente iSCSI conectado ao destino iSCSI estava no meu ambiente ~ 20 IOPS, com taxa de transferência (dependendo do tamanho do IO) ~ 2- 3 MiB / s. Alterei o controlador de disco virtual dentro da máquina virtual para SCSI e posso obter mais de 1000 IOPS e obter mais de 100 MiB / s de meus clientes 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>