Eu tenho um convidado do Windows 2k3r3 de 32 bits (servidor de terminal) com 4 GB de RAM convidado e troca.
Criei uma imagem de disco separada para troca de convidados e diretórios temporários do usuário.
Tenho RAM suficiente no sistema host e quero salvar a E/S do disco movendo esta imagem para tmpfs, mas o convidado não inicia com esta mensagem de erro:
qemu-kvm: -drive file=/mnt/tmpfs/vh1-tmp.qcow2,if=none,id=drive-ide0-1-1,format=qcow2,cache=none: não foi possível abrir o disco imag│ 4098 qemu 20 0 4949M 4146M 5496 S 28,5 17,2 1h00:31 /usr/bin/qemu-kvm -name vh1 -S -M pc-1.3 -cpu kvm64 -enable- e /mnt/tmpfs/vh1-tmp.qcow2: argumento inválido
Sistema hospedeiro:
#unome -a
Linux srv-vh1.su.local 3.7.10-1.16-default #1 SMP Sex, 31 de maio 20:21:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
srv-vh1:/mnt/tmpfs # versão virsh
Compilado na biblioteca: libvirt 1.0.2
Usando biblioteca: libvirt 1.0.2
Usando API: QEMU 1.0.2
Executando hipervisor: QEMU 1.3.0
srv-vh1:/mnt/tmpfs # grátis
total de buffers compartilhados livres usados armazenados em cache
Memória: 24627548 5084724 19542824 0 60640 138792
-/+ buffers/cache: 4885292 19742256
Troca: 8384444 0 8384444
srv-vh1:/mnt/tmpfs # cat /etc/mtab | greptmpfs
devtmpfs /dev devtmpfs rw,relatime,size=12296608k,nr_inodes=3074152,mode=755 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
tmpfs /mnt/tmpfs tmpfs rw,relatime 0 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
tmpfs /tmp tmpfs rw,relatime 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
srv-vh1:/mnt/tmpfs#df
Sistema de arquivos 1K blocos usados Disponível Usado% Ponto de montagem
devtmpfs 12296608 68 12296540 1% /dev
tmpfs 12313772 0 12313772 0% /dev/shm
tmpfs 12313772 6772 12307000 1% /execução
/dev/md1 454131992 218835836 212227596 51% /
tmpfs 12313772 0 12313772 0% /sys/fs/cgroup
tmpfs 12313772 192 12313580 1% /mnt/tmpfs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
tmpfs 12313772 20 12313752 1% /tmp
tmpfs 12313772 6772 12307000 1% /var/lock
tmpfs 12313772 6772 12307000 1% /var/executar
srv-vh1:/mnt/tmpfs # virsh pool-info tmpfs
Nome: tmpfs
UUID: 6287028a-9faf-f762-20de-d36d63657be3
Situação: trabalhando
Persistente: sim
Inicialização automática: sim
Capacidade: 11,74 GiB
Valor: 0,00
Disponível: 11,74 GiB
srv-vh1:/mnt/tmpfs # ls -la
total 196
drwxrwxrwt 2 root root 60 de setembro 9 11:42 .
drwxrwxr-x 4 qemu qemu 4096 8 de setembro 19:39 ..
-rw-rw-rw- 1 root root 197120 9 de setembro 11:42 tserver-tmp.qcow2
O que estou fazendo de errado ?
Responder1
Aparentemente, se você definir cache=NONE para um arquivo de imagem de disco em qualquer sistema de arquivos host que não suporte Direct IO, o Virt-Manager atualmente exibirá uma mensagem de erro não muito útil dizendo "Alguma coisa... Argumento inválido" e se recusará a iniciar a VM convidada.
Um exemplo de tal sistema de arquivos – que não suporta Direct IO – é o tmpfs. Outro sistema de arquivos onde talvez você possa desativar opcionalmente o Direct IO é o GlusterFS (do qual eu não tinha ouvido falar antes, também tive o mesmo problema que Sergei e estava pesquisando o erro). Para tmpfs, não suportar Direct IO parece ser uma limitação técnica. ou conflito de design no momento e não sei se será/pode ser corrigido no futuro.
No meu caso, coloquei um Ramdisk de 3,6 GB para uma VM convidada Win7Pro em execução no CentOS7 e configurei cache=NONE para o ramdisk no Virt-Manager. As outras opções que o tmpfs img usou foram virtio e raw. A VM se recusaria a iniciar com o mesmo erro/semelhante dizendo "... Argumento inválido".
Para obter detalhes técnicos e notas diretamente do engenheiro e desenvolvedor Redhat que codificou o patch para o feature cache=NONE e mantém (?) Virt-Manager (Daniel Berrange), consulte a discussão no seguinte link:
https://bugs.launchpad.net/nova/+bug/959637
Para citar Daniel do URL acima: "> não foi possível abrir a imagem de disco /mnt/vmstore/instances/instance-0000001a/disk: argumento inválido
provavelmente significa que o sistema de arquivos não suporta Direct IO. AFAIK, todos os sistemas de arquivos, exceto tmpfs, devem suportar isso.."
Além disso, Daniel continua: "- Então, o que queremos fazer é [....] verificar se o volume de armazenamento suporta Direct IO. Se isso acontecer, use cache=none, caso contrário, retorne para cache= writethrough que não usa Direct I/O, mas ainda é seguro contra falhas."
No meu caso, consegui verificar se a configuração cache=NONE para o arquivo tmpfs img NÃO estava iniciando a VM e mostrou o erro conforme discutido. Foi possível iniciar a VM com êxito se o cache foi definido como "Padrão" ou explicitamente como "Write-through". Não faz sentido usar o "Write-back", já que esse sistema de arquivos é dispensável e, de qualquer forma, está inteiramente na RAM, então obviamente eu não usei o Write-back.
Espero que ajude!
Responder2
Por que não dar ao convidado mais memória RAM para que ele não precise trocar?
srv-vh1:/mnt/tmpfs # ls -la
total 196
drwxrwxrwt 2 root root 60 сен 9 11:42 .
drwxrwxr-x 4 qemu qemu 4096 сен 8 19:39 ..
-rw-rw-rw- 1 root root 197120 сен 9 11:42 tserver-tmp.qcow2
Percebi que você tem o proprietário da pasta definido como qemu:qemu. Se você estiver executando o qemu como um usuário diferente, talvez queira alterar o proprietário do arquivo de imagem de root para qemu
Responder3
É um bug. tmpfs não suporta cache=none.