qemu não inicia busca com imagem de disco em tmpfs

Question

Eu tenho 32bit windows 2k3r3 guest (servidor de terminal) com memória RAM e swap de 4GB.

Eu criei imagem de disco separada para troca de convidados e diretórios temporários do usuário.

Eu tenho uma RAM no sistema host e quero salvar o disco IO movendo esta imagem para tmpfs, mas o convidado não começa 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: could not open disk 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: Invalid argument

Sistema host:

#uname -a
Linux srv-vh1.su.local 3.7.10-1.16-default #1 SMP Fri May 31 20:21:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

srv-vh1:/mnt/tmpfs # virsh version
Compiled against library: libvirt 1.0.2
Using library: libvirt 1.0.2
Using API: QEMU 1.0.2
Running hypervisor: QEMU 1.3.0

srv-vh1:/mnt/tmpfs # free
             total       used       free     shared    buffers     cached
Mem:      24627548    5084724   19542824          0      60640     138792
-/+ buffers/cache:    4885292   19742256
Swap:      8384444          0    8384444

srv-vh1:/mnt/tmpfs # cat /etc/mtab | grep tmpfs
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
Filesystem  1K-blocks used      Avaible     Used%          Mountpoint
devtmpfs          12296608           68  12296540            1% /dev
tmpfs             12313772            0  12313772            0% /dev/shm
tmpfs             12313772         6772  12307000            1% /run
/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/run

srv-vh1:/mnt/tmpfs # virsh pool-info tmpfs
Name:         tmpfs
UUID:           6287028a-9faf-f762-20de-d36d63657be3
Status:   working
Persistent:     yes
Autostart: yes
Capacity: 11,74 GiB
Выделение: 0,00 
Avaible: 11,74 GiB

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

O que estou fazendo de errado?

    

Answer 1

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 fornecerá uma mensagem de erro não muito útil dizendo "Algo algo ... 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 desse tipo, onde talvez você possa desativar opcionalmente o Direct IO, é o GlusterFS (que eu não tinha ouvido falar antes mesmo de ter o mesmo problema do Sergei e estar pesquisando o erro.) Para tmpfs, não suportar o Direct IO parece ser uma limitação técnica. ou conflito de design no momento e não sei se será / poderá ser corrigido no futuro.

No meu caso, eu tinha colocado um Ramdisk de 3,6 GB para uma VM Win7Pro Guest rodando no CentOS7 e tinha set cache = NONE para o ramdisk no Virt-Manager. As outras opções que os tmpfs img usaram foram virtio e raw. A VM se recusaria a começar com o mesmo erro / erro dizendo "... argumento inválido".

Para detalhes técnicos e notas diretamente do Redhat Engineer e Developer que codificou o patch para o cache de recursos = NONE & mantém (?) Virt-Manager (Daniel Berrange), veja a discussão no seguinte link:

link

Para citar Daniel no URL acima:  "> não pôde abrir imagem de disco / mnt / vmstore / instances / instance-0000001a / disk: argumento inválido

provavelmente significa que o sistema de arquivos não suporta o Direct IO. ATÉ ONDE SEI,    todos os sistemas de arquivos, exceto o tmpfs, devem suportar isso .. "

Além disso, Daniel continua:  "- Então o que vamos querer fazer então é [....] checar se o    volume de armazenamento suporta Direct IO. Em caso afirmativo, use cache = none,    caso contrário, fallback to cache = writethrough que não usa Direct    E / S, mas ainda está seguro contra falhas. "

No meu caso, eu pude verificar que a configuração cache = NONE para o arquivo tmpfs img NÃO estava iniciando a VM e mostrou o erro como discutido. Ele foi capaz de iniciar com êxito a VM se o cache foi definido como "Padrão" ou explicitamente como "Gravação por gravação". Não faz sentido usar o "Write-back", já que este sistema de arquivos é descartável e, de qualquer forma, é inteiramente na RAM, então obviamente eu não usei Write-back.

Espero que ajude!

    

Answer 2

Por que não dar mais memória ao visitante 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

Eu notei que você tem o proprietário da pasta configurado como qemu: qemu, se você estiver executando o qemu como um usuário diferente, então você pode querer alterar o proprietário do arquivo de imagem da raiz para qemu

    

Answer 3

É um bug. O tmpfs não suporta cache=none .