100% de utilização da CPU e travar após virsh migrate

Question

Eu tenho experimentado com a migração ao vivo do ZFS + DRBD + (eu quero entendê-lo bem o suficiente para escrever meus próprios scripts de automação antes de começar a jogar com ganeti novamente, e então abra a estaca cinder ). Eu tenho o ZFS + DRBD (no modo dual-primário) funcionando bem para armazenamento compartilhado.

No entanto, a migração ao vivo funciona apenas parcialmente.

Eu tenho dois hosts, com configurações de libvirt e drbd idênticas, e até mesmo pool de "volumes" dedicados idênticos para VM ZVOLs (ambos os pools de 2x1TB - reutilizando alguns discos antigos do meu antigo pool de backup) e configurações idênticas para VM (chamado "dtest")

• "indra" é um AMD FX-8150 com 16GB de RAM em um ASUS Sabertooth 990FX m / b

  • sinalizadores de cpu: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

• "surya" é um AMD Phenom II X4 940 com 8GB de RAM em um ASUS M3A79-T DELUXE m / b

  • cpu flags fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save

Ambos estão rodando o debian sid, com exatamente as mesmas versões de pacotes (incl. libvirt* 2.0.0-1:amd64 e qemu-system-x86 1:2.6+dfsg-3 ), e com o mesmo kernel liquorix:

Linux indra 4.6-2.dmz.2-liquorix-amd64 #1 ZEN SMP PREEMPT Debian 4.6-3 (2016-06-19) x86_64 GNU/Linux
Linux surya 4.6-2.dmz.2-liquorix-amd64 #1 ZEN SMP PREEMPT Debian 4.6-3 (2016-06-19) x86_64 GNU/Linux

A própria VM está executando o debian sid, com um kernel debian 4.6.0-1:

Linux dtest 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64 GNU/Linux

Eu posso iniciar a VM em qualquer um dos hosts e ela funciona perfeitamente.

Eu posso migrar uma VM de surya para indra sem nenhum problema. Quando tento migrar a VM de indra para surya, a migração parece ser concluída com êxito, mas a VM trava com 100% de uso da CPU (para o único núcleo alocado a ela).

Não faz diferença se a VM foi iniciada em indra e depois migrada para surya (onde ela trava) ou se foi iniciada em surya, migrada para indra (OK até agora) e depois migrada de volta para surya (trava).

A única coisa que posso fazer com a VM quando ela é interrompida é virsh destroy (force-shutdown) ou virsh reset (force-reboot).

Eu tentei desativar o kvm_steal_time com:

 <qemu:commandline>
   <qemu:arg value='-cpu'/>
   <qemu:arg value='qemu64,-kvm_steal_time'/>
 </qemu:commandline>

mas isso não resolve o problema.

Nada é registrado ou da própria VM. A única indicação que recebo de qualquer problema é a seguinte mensagem em /var/log/libvirt/qemu/dtest.log on surya.

2016-07-18T12:56:55.766929Z qemu-system-x86_64: warning: TSC frequency mismatch between VM and host, and TSC scaling unavailable

Isso seria devido ao recurso tsc_scale cpu - presente no processador 8150 (indra), ausente no x4 940 (surya).

Alguém sabe qual é o problema? Ou como consertar isso? ou sugestões para depuração?

É mesmo consertável, ou é um bug da CPU no Phenom II x4 940 de várias gerações?

    

Answer 1

Eu encontrei uma solução.

Como eu suspeitava, a causa do problema foi a falta de tsc_scale nos sinalizadores de recursos da CPU de surya.

Acontece que você pode migrar uma VM de um host sem tsc_scale para um host com ela, mas uma VM em execução em um host com tsc_scale pode SOMENTE ser migrada para outro host com isso.

Hora de enviar um relatório de erros.

Eu criei outro DRBD baseado em ZFS ZVOL, desta vez entre surya e outra máquina na minha rede, meu servidor principal ganesh .

• ganesh é um AMD Phenom II 1090T com 32GB de RAM em um ASUS Sabertooth 990FX m / b
  • Sinalizadores de CPU: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter

Eu posso migrar uma VM entre surya e ganesh, sem problemas e posso migrar uma VM de surya ou ganesh para indra. Mas não consigo migrar uma VM de indra para surya ou ganesh .

Eu posso viver com isso por enquanto. O ganesh deve ser atualizado quando os novos processadores AMD Zen forem lançados, e surya terá a placa-mãe e a RAM atuais do ganesh. Eu vou comprar um novo FX-6300 ou FX-8320 para ele ao mesmo tempo, então todas as máquinas terão tsc_scale .

Eu tenho outra máquina (kali) na rede com uma CPU FX-8320 (que também possui o recurso tsc_scale ). Eu já estava planejando adicionar isso aos experimentos de migração ao vivo ZVOL + DRBD + assim que eu atualizo o zpool principal no ganesh (de 4x1TB RAIDZ para 2x4TB espelhado) e libero mais alguns discos antigos, então eu poderei migrar VMs para frente e para trás entre indra e kali, ou entre surya e ganesh.

A próxima fase no meu plano de experimentação de VM é escrever scripts para automatizar completamente o processo de configuração de uma VM para usar o DBRD no ZVOL e migrar VMs entre máquinas host.

Quando eu tiver isso funcionando bem, vou acabar com ele e começar a trabalhar com o ganeti, que já faz o que eu estou planejando escrever (mas mais completo e melhor).

E finalmente, quando me canso disso, mudo para o openstack e uso o cinder para o gerenciamento de volume. Estou tentado a pular o ganeti e ir direto para o openstack, mas o ganeti é uma tecnologia tão legal que eu quero jogar com ele por um tempo ... Eu não o uso há anos.