Como converter uma imagem de disco bruta em uma imagem copy-on-write baseada em outra imagem para uso com o kvm e virt-manager?

Question

Eu tenho uma máquina virtual do Windows em execução no kvm. Atualmente, ele possui uma imagem de disco bruto de 90 GB. Eu gostaria de clonar essa VM sem ter que manter duas cópias da imagem de disco bruto de 90 GB.

Parece que uma boa abordagem para fazer isso é fazer duas novas imagens qcow ou qcow2 baseadas no original. Primeiro converti a imagem bruta em uma imagem qcow2:

qemu-img convert -O qcow2 basewindowsxp.img basewindowsxp.qcow2

Então, tentei criar uma nova imagem com este suporte:

qemu-img create -F qcow2 -f qcow2 -b 'pwd'/basewindowsxp.qcow2 windowsxp-1.qcow2

Depois usei o virt-manager para apontar a VM original em windowsxp-1.qcow2. No entanto, quando tento inicializar a VM nessa nova configuração, o virt-manager relata um erro:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 588, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 150, in startup
    self._backend.create()
  File "/usr/lib/python2.6/dist-packages/libvirt.py", line 300, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open disk image /var/lib/libvirt/images/windowsxp-1.qcow2

O erro sugere que o nome do arquivo foi especificado incorretamente ou que as permissões do sistema de arquivos são muito restritivas, mas nenhuma delas é o caso:

$ ls -l /var/lib/libvirt/images/windowsxp-1.qcow2 
-rwxrwxrwx 1 root root 262144 2010-05-27 08:32 /var/lib/libvirt/images/windowsxp-1.qcow2

Por que o virt-manager não inicia este vm?

    

Answer 1

Esse problema foi causado pela forma como o libvirt usa o apparmor.

O comportamento padrão é fornecer alguma proteção para o host em relação ao convidado, restringindo quais arquivos o processo de virtualização no host pode acessar. A libvirt sabe que o processo de virtualização (kvm, neste caso) precisa da imagem do disco para funcionar corretamente, então cria um perfil apparmor que permite acesso a windowsxp-1.qcow2 . No entanto, ele não sabe que windowsxp-1.qcow2 é suportado por basewindowsxp.qcow2 , portanto, o perfil apparmor não permite acesso a esse arquivo.

É lamentável que o relatório de erros do kvm seja tão mínimo. A falha subjacente foi quase certamente um EPERM ao abrir basewindowsxp.qcow , mas aparentemente esse erro é achatado e a informação útil é perdida.

No entanto, a leitura dos registros do sistema revelará que o apparmor está fazendo alguma coisa. Por exemplo,

28 de maio 13:12:28 hostname kernel: [5338.835932] type = 1503 audit (1275066748.269: 42): operação="abrir" pid = 10601 pai = 1 profile="libvirt-b1a29fd0-698c-11df-9c21- f78cb972735d "requested_mask=" :: w "denied_mask=" :: w "fsuid = 0 ouid = nome 1001=" / var / lib / libvirt / images / basewindowsxp.img "

Isso mostra o que acontece quando um perfil apparmor nega acesso de gravação a um arquivo para um processo. Cada vez que a inicialização da VM falhou por causa dessa configuração incorreta, esta mensagem de log apareceu em / var / log / messages.

Existem várias soluções possíveis para o problema.

1) Desativar a proteção do apparmor. Isso é controlável por meio da GUI do virt-manager. Na seção de visão geral, subseção de segurança, apparmor pode ser desativado.

2) Permitir manualmente o acesso ao arquivo extra. Isso é controlado modificando os arquivos apparmor no diretório /etc/apparmor.d/libvirt/. Adicionando uma linha como:

"/var/lib/libvirt/images/basewindowsxp.img" r,

para o arquivo que corresponde ao uuid da vm em questão concederá acesso de leitura ao nome do arquivo entre aspas.

3) Atualize para uma versão mais nova do apparmor / libvirt / a plataforma base e recrie as VMs. Aparentemente, essa configuração incorreta foi notada e é endereçada automaticamente em versões novas o suficiente do software em questão.