Pouco de contexto. Poucas VMs rodando no KVM (SmartOS), usando o kernel 2.6.32.7, foram reiniciadas. Nada nos logs do Qemu / KVM para sugerir que é um problema do Qemu.
Infelizmente ao testar o kdump eu descobri um problema que faz o kernel do kdump entrar em pânico ao gravar o disco de despejo no driver virtio blk.Então eu decidi apenas configurar o kernel para logar em um dispositivo serial para capturar um rastreio de pilha. Teve uma máquina reinicializada e nada além de seqüência de inicialização, nenhum rastreamento de pilha. O printk inicial também é definido na configuração do kernel.
Embora essas VMs sejam surpreendidas e aprovadas novamente usando uma imagem mais nova, ela levantou uma questão.
Por exemplo, porque a VM está reinicializando em primeiro lugar, o Qemu não está saindo e foi iniciado por um processo externo que o convidado está reinicializando claramente (sem limpeza devido ao estado de ext na inicialização).No entanto, o AFAIK não deve ser reinicializado, seja pânico, oops, travamento suave ou hardlockup, ele deve permanecer ativo (mesmo que esteja bloqueado) kernel.panic systcl é definido como 0.
kernel.panic = 0
kernel.panic_on_oops = 0
kernel.unknown_nmi_panic = 0
kernel.panic_on_unrecovered_nmi = 0
kernel.panic_on_io_nmi = 0
kernel.softlockup_panic = 0
kernel.hung_task_panic = 0
vm.panic_on_oom = 0
O que mais poderia fazer com que o kernel do linux decidisse reinicializar, ou eu estou interpretando mal qualquer um dos sysctls acima?