Libvirt qemu alterando identificadores de hardware?

3

Estou tendo um problema estranho que simplesmente não consigo entender. Eu tenho uma máquina virtual do Windows 7 que era originalmente uma máquina física que foi rebaixada para uma VM há algum tempo. Eu usei para inicializar com

qemu-system-x86_64 --enable-kvm -vga std -m 4G -smp cores=4 /path/to/image 

Ele alterou minhas informações de hardware o suficiente para acionar qualquer ativação do Windows. Eu comecei recentemente usando libvirt e virt-manager. Tudo correu bem até que comecei a importar esta máquina Windows. Uma vez que eu finalmente consegui arrancar, isso desencadeou um disparate de ativação do Windows.

Eu tirei screenshots das especificações de hardware relatadas (msinfo32), encerrei, fiz o boot com o comando não-problemático e comparei o hardware reportado. Tudo parecia o mesmo. Então comecei a brincar com a WMIC para ver se conseguia informações mais detalhadas. A única coisa que notei foi que o campo CPU ProcessorID era diferente entre as duas botas. Eu tentei todos os tipos de ajustes na minha configuração (principalmente, os parâmetros cpu (match = 'exato', modo = 'host modelo', mode = 'host-passthrough', etc)) usando virsh edit machinename , mas sem sucesso .

Usando ps, posso ver que o libvirt está executando o seguinte comando (dividido em várias linhas para facilitar a leitura):

qemu-system-x86_64 -enable-kvm -name win7 -S \
-machine pc-i440fx-trusty,accel=kvm,usb=off -m 4096 \ 
-realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 \
-uuid 71ca9116-a4a1-b799-dab5-01a483bce024 \
-no-user-config -nodefaults \
-chardev socket,id=charmonitor,path=/var /lib/libvirt/qemu/win7.monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown -boot strict=on \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-drive file=/media/paul/VirtualMachines/win7.vmdk,if=none,id=drive-ide0-0-0,format=vmdk \
-device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 \
-netdev tap,fd=25,id=hostnet0 \
-device \
    rtl8139, \
    netdev=hostnet0, \
    id=net0, \
    mac=52:54:00:bf:2c:b2,bus=pci.0, \
    addr=0x3 -chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-device usb-tablet,id=input0 -vnc 127.0.0.1:0 \
-device VGA,id=video0,bus=pci.0,addr=0x2 \
-device intel-hda,id=sound0,bus=pci.0,addr=0x4 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

Aqui está o meu arquivo de configuração: link

Ainda posso inicializar com o comando simples e não há problema. O comando libvirt qemu deve ter mudado alguma coisa sobre como meu hardware é relatado para a máquina convidada. Eu notei parâmetros que parecem estar definindo um endereço mac e disco rígido uuid, mas isso não importa. Tenho certeza de que o bloqueio de hardware do Windows é principalmente baseado em uma combinação de placa-mãe e / ou cpu.

Alguém tem uma ideia de por que isso pode estar acontecendo e como corrigi-lo?

UPDATE

Eu tentei executar o comando qemu que o libvirt estava rodando acima diretamente, removendo argumentos até que ele fosse inicializado, e então até que o Windows mostrasse que ele estava ativado. Parece que o -uuid causou o problema. Não tenho certeza do porquê. Eu pensei que o argumento uuid era apenas para o perfil de segurança (no meu caso, o AppArmor), mas parece também mudar algum identificador de hardware no guest?

Na inicialização bem-sucedida, executei wmic csproduct get uuid no Windows, copiei e desliguei. Então fiz o seguinte:

virsh dumpxml win7 > win7.xml
virsh undefine win7
[Edited win7.xml -> changed uuid to match the one I copied]
virsh define win7.xml

Eu abri o virt-manager e inicializei. Funcionou! Parece que o uuid define o número de série da placa-mãe? Curiosamente, a minha era uma string de 0 (aparentemente, muitas placas não reportam um uuid), então não foi realmente único, tornando toda essa aventura muito boba.

Eu não postei isso como uma resposta, porque não sei por que isso funcionou (eu apenas hackeei até funcionar e estou fazendo suposições acima). Talvez alguém mais bem informado sobre o assunto possa postar uma resposta melhor?

    
por Paul Nordin 15.09.2016 / 01:27

0 respostas