Renovação de Certificados no OLVM (Oracle Linux Virtualization Manager)
Versão testada: OLVM 4.4.10.7-1.0.18.el8
Frequência recomendada: anual (certificados expiram em \~395 dias)
Pré-requisito crítico: backup completo antes de qualquer alteração
Visão geral
O OLVM usa uma PKI interna própria para autenticar comunicação entre o Engine, os hosts (VDSM/libvirt), o console noVNC/SPICE, o OVN e outros componentes. Todos esses certificados têm validade limitada e, quando expiram, geram falhas de conexão silenciosas — hosts saem como "Não responsivo", consoles de VM parecem fora do ar, e logs mostram erros de handshake TLS.
Este guia documenta o processo completo de renovação, cobrindo quatro frentes que não acontecem automaticamente em conjunto:
As frentes 3 e 4 cobrem o mesmo tipo de certificado (host/VDSM), mas por caminhos diferentes: a frente 3 é o processo manual host-a-host; a frente 4 é o script oficial da Oracle que automatiza isso para um host, um cluster, ou todo o ambiente de uma vez. Use a frente 4 quando tiver vários hosts ou preferir o método suportado oficialmente.
Importante: este procedimento é para ambientes onde os certificados já expiraram. Se for uma renovação preventiva, o fluxo é o mesmo, mas o risco de indisponibilidade durante a execução é bem menor.
Antes de começar
-
Confirme se o Engine é standalone ou self-hosted.
-
-
Se for self-hosted, ative o modo de manutenção primeiro, conforme Doc ID 3006292.1 (Oracle Support).
-
-
Garanta acesso root via SSH ou console.
-
Tenha uma janela de manutenção, pois alguns serviços reiniciam durante o processo.
-
Tenha espaço em disco suficiente para o backup (o
engine-setuptambém fará um backup interno do banco).
Etapa 1 — Backup do ambiente
Sempre rode o backup manual antes de iniciar, independente do backup que o engine-setup oferece fazer:
engine-backup --scope=all --mode=backup \
--file=/root/bkpcertificado.bck \
--log=/root/bkpcertificado.log
Isso garante um ponto de retorno completo (configuração + banco) caso algo saia do previsto.
Etapa 2 — Renovação via engine-setup
Inicie o processo:
engine-setup --offline
O assistente fará uma série de perguntas. Veja como responder cada uma:
Ao final, o engine-setup reinicia automaticamente os serviços do Engine (httpd, engine, dwh, websocket-proxy, grafana-server, etc.) e exibe um resumo com URLs de acesso e fingerprint SSH atualizado.
Nota: esse passo renova boa parte dos certificados, mas não todos. Alguns (OVN, vmconsole-proxy) ficam de fora e precisam da Etapa 4.
Etapa 3 — Verificando o que foi renovado
Liste a validade de todos os certificados do Engine:
cd /etc/pki/ovirt-engine/certs/
for cert in *.cer; do
echo "Certificate: $cert"
openssl x509 -in "$cert" -noout -dates
echo
done
Compare as datas notAfter — qualquer certificado ainda com data antiga (próxima ou já expirada) precisa de correção manual na próxima etapa. Tipicamente isso afeta:
-
-
ovirt-provider-ovn.cer -
ovn-ndb.cer -
ovn-sdb.cer -
vmconsole-proxy-helper.cer -
vmconsole-proxy-user.cer -
vmconsole-proxy-host.cer
Etapa 4 — Corrigindo certificados não renovados
4.1 Descubra o subject correto
Use um certificado válido existente como referência para manter o mesmo padrão de subject:
openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -subject
Exemplo de saída:
subject=C = US, O = exemplo.local, CN = olvm-mv-02.exemplo.local
4.2 Reemita os certificados pendentes
Com o subject em mãos, rode o script pki-enroll-pkcs12.sh para cada serviço pendente:
cd /etc/pki/ovirt-engine/certs
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="ovirt-provider-ovn" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="ovn-ndb" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="ovn-sdb" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="vmconsole-proxy-helper" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="vmconsole-proxy-user" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="vmconsole-proxy-host" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
⚠️ Ajuste
--subjecte--passwordpara o seu ambiente. O subject deve refletir exatamente o domínio/FQDN do seu OLVM.
4.3 Reinicie os serviços afetados
systemctl restart ovirt-provider-ovn.service
systemctl restart ovn-northd.service
systemctl restart ovirt-vmconsole-proxy-sshd.service
Confirme que todos subiram com systemctl status antes de seguir.
Etapa 5 — Renovação do certificado VDSM
O certificado VDSM controla a comunicação Engine ↔ Host e também é reutilizado pelo SPICE/libvirt. Use o mesmo subject identificado na Etapa 4.1.
# 1. Gere o CSR a partir da chave existente
mkdir /root/vdsm
cd /etc/pki/vdsm/keys/
openssl req -new -key vdsmkey.pem -out /root/vdsm/vdsm.csr \
-passin "pass:mypass" -passout "pass:mypass" -batch -subj "/"
# 2. Assine o CSR com a CA interna do oVirt, válido por 10 anos
cd /etc/pki/ovirt-engine/
openssl ca -batch -policy policy_match -config openssl.conf \
-cert ca.pem -keyfile private/ca.pem -days +3650 \
-in /root/vdsm/vdsm.csr -out /root/vdsm/vdsm.cer \
-startdate "$(date --utc --date "now -1 days" +"%y%m%d%H%M%SZ")" \
-subj "/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" -utf8
# 3. Substitua o certificado VDSM (mantendo backup do antigo)
cd /etc/pki/vdsm/certs/
cp -a vdsmcert.pem vdsmcert.pem.old
cat /root/vdsm/vdsm.cer > vdsmcert.pem
# 4. Propague o novo certificado para SPICE e libvirt
cd /etc/pki/vdsm/libvirt-spice/
cp -a server-cert.pem server-cert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > server-cert.pem
cp -a /etc/pki/libvirt/clientcert.pem /etc/pki/libvirt/clientcert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > /etc/pki/libvirt/clientcert.pem
# 5. Reinicie os serviços do host
systemctl restart libvirtd vdsmd
systemctl status libvirtd vdsmd
Confirme a nova validade:
openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -dates
O certificado deve agora expirar 10 anos no futuro (-days +3650), em vez do prazo padrão de 1 ano usado pelo engine-setup.
Etapa 6 — Renovando certificados dos Hypervisors com o script OlvmKvmCerts
A Oracle disponibiliza um script oficial, o OlvmKvmCerts, que automatiza a checagem e a renovação de certificados em um ou mais Hypervisors (KVM hosts) diretamente do Engine — sem precisar repetir manualmente os passos da Etapa 5 em cada host. É documentado no Doc ID 3008653.1 da Oracle Support.
Quando usar: ambientes com múltiplos hosts, ou quando o método manual (Etapa 5) já foi feito num host e você quer aplicar o mesmo resultado nos demais de forma rápida e auditável.
Quando NÃO usar como primeira opção: o método recomendado pela própria Oracle continua sendo colocar o host em manutenção e usar a opção "Enroll" do Admin Portal. O script é descrito oficialmente como uma "medida de emergência" para quando o certificado já expirou e o enroll preventivo não foi feito a tempo.
Compatibilidade: testado pela Oracle em OLVM 4.3, 4.4 e 4.5, em Oracle Linux 7.9 ou superior.
⚠️ Se o Engine também estiver com certificados expirados, renove-os primeiro (Etapas 1–5 / Doc ID 3006292.1) antes de rodar este script.
6.1 Download e preparação
Baixe a versão mais recente do script (anexa ao Doc ID 3008653.1) e copie para o Engine — o script só roda lá, nunca direto em um Hypervisor.
chmod 755 OlvmKvmCerts
chown root:root OlvmKvmCerts
6.2 Desabilite o Cluster Fencing antes de rodar
No Admin Portal do OLVM, desabilite o fencing do cluster antes de executar o script. O próprio script desabilita/reabilita o power management do host durante o processo, mas alguns hosts demoram a reportar o status correto — fencing ativo nesse intervalo pode causar reinício indesejado do host.
6.3 Comandos disponíveis
./OlvmKvmCerts
Usage: OlvmKvmCert [OPTION] <HOST|CLUSTER>
status Exibe o status de todos os certificados no Engine
list-hosts Lista todos os Hypervisors
renew-host <HOST> Renova os certificados de um único Hypervisor
renew-cluster <CLUSTER> Renova os certificados de todos os Hypervisors de um Cluster
renew-all Renova os certificados de todos os Hypervisors
check-host <HOST> Verifica todos os certificados de um único Hypervisor
check-cluster <CLUSTER> Verifica todos os certificados de todos os Hypervisors de um Cluster
check-all Verifica todos os certificados de todos os Hypervisors
6.4 Exemplos de uso
Ver a validade de todos os certificados do Engine:
./OlvmKvmCerts status
engine.cer Dec 15 10:23:05 2028 GMT
jboss.cer Dec 15 10:23:06 2028 GMT
websocket-proxy.cer Jan 16 10:23:06 2025 GMT
apache.cer Jan 16 10:23:06 2025 GMT
reports.cer Dec 15 10:23:06 2028 GMT
ovn-ndb.cer Dec 15 10:23:06 2028 GMT
ovn-sdb.cer Dec 15 10:23:07 2028 GMT
ovirt-provider-ovn.cer Dec 15 10:23:07 2028 GMT
vmconsole-proxy-helper.cer Dec 15 10:23:09 2028 GMT
vmconsole-proxy-user.cer Dec 15 10:23:09 2028 GMT
vmconsole-proxy-host.cer Dec 15 10:23:09 2028 GMT
hypervisor1.exemplo.local.cer Mar 6 16:53:36 2029 GMT
hypervisor2.exemplo.local.cer Mar 6 16:56:38 2029 GMT
Listar todos os hosts gerenciados:
./OlvmKvmCerts list-hosts
name | host | cluster
------------+------------------------+---------
hypervisor1 | hypervisor1.exemplo.local | Default
hypervisor2 | hypervisor2.exemplo.local | Default
Checar (sem alterar) os certificados de um host específico:
./OlvmKvmCerts check-host hypervisor1.exemplo.local
O script valida, host a host: conectividade, certificado e chave privada do VDSM, libvirt-migrate, libvirt-spice, libvirt-vnc e OVN — confirmando cada item com [PASS] ou apontando falha.
Renovar os certificados de um host:
./OlvmKvmCerts renew-host hypervisor2.exemplo.local
O script executa, nessa ordem, para o host informado:
-
Backup local dos certificados atuais
-
Geração de nova chave/CSR e assinatura pela CA do Engine (VDSM, libvirt, libvirt-spice, libvirt-vnc)
-
Cópia dos novos certificados para o host
-
Mesmo processo para o certificado OVN
-
Geração do certificado libvirt-migrate (quando aplicável à versão do OLVM)
-
Desabilita o power management do host, reinicia os serviços afetados, espera o host voltar para "Available" e reabilita o power management
6.5 Pós-execução
-
-
No Admin Portal, reabilite o Cluster Fencing caso tenha desabilitado no passo 6.2.
-
O script guarda um backup temporário dos certificados anteriores em
/var/tmpem cada host — útil para rollback manual caso algo dê errado (basta extrair, copiar os arquivos de volta para os caminhos originais e reiniciar os serviços). -
Mesmo após a renovação via script ser bem-sucedida, é recomendado, posteriormente, agendar uma manutenção e fazer o "Enroll" do host pelo Admin Portal — o script é uma correção de emergência, não substitui o fluxo oficial de longo prazo.
Histórico de correções do script (para referência)
Se, após a renovação, o console noVNC apresentar "Something went wrong, connection is closed" e o /var/log/messages mostrar erro de criptografia, ajuste as permissões da chave Apache e force o websocket-proxy a usar o certificado correto:
chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass
cp -a /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf \
/etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf
vim /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf
Adicione (ou confirme) as linhas no arquivo 99-setup.conf:
SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass
Reinicie o serviço:
systemctl restart ovirt-websocket-proxy.service
Se ainda não funcionar: importe a CA como intermediária no navegador
-
Acesse, substituindo pelo FQDN do seu OLVM:
https://FQDN/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA -
Renomeie o arquivo baixado para extensão
.pem. -
No navegador (ex.: Chrome), importe esse
.pemem:
Configurações → Privacidade e segurança → Gerenciar certificados → Autoridades de Certificação Intermediárias → Importar
Isso resolve casos em que o browser ainda desconfia da nova cadeia de certificação mesmo com os serviços corretamente configurados.
Checklist final
-
-
Backup
engine-backuprealizado e armazenado fora do servidor -
engine-setup --offlineconcluído sem erros -
Todos os
.cerem/etc/pki/ovirt-engine/certs/comnotAfteratualizado -
Certificados OVN e vmconsole-proxy reemitidos manualmente (se necessário)
-
Certificado VDSM renovado e propagado para SPICE/libvirt
-
\(Alternativa)\ Cluster Fencing desabilitado antes de rodar o
OlvmKvmCerts -
\(Alternativa)\
OlvmKvmCerts check-alloustatusconfirmando validade atualizada em todos os hosts -
\(Alternativa)\ Cluster Fencing reabilitado após o script
-
\(Alternativa)\ Hosts re-enrolados via Admin Portal após uso do script (boa prática pós-emergência)
-
Serviços
ovirt-provider-ovn,ovn-northd,ovirt-vmconsole-proxy-sshd,libvirtd,vdsmdativos -
Console noVNC testado e funcional
-
Host validado como "Up" no painel do OLVM
Referências
-
-
Eclipsys — OLVM Renew Engine and KVM Certificate
-
Oracle Support — Doc ID 3006292.1 (modo de manutenção em ambiente self-hosted)
-
Oracle Support — Doc ID 2960024.1 (atualização de certificados não renovados pelo engine-setup)
-
Oracle Support — Doc ID 2922244.1 (importação de CA intermediária no navegador)
-
Oracle Support — Doc ID 3008653.1 (script
OlvmKvmCerts— checagem e renovação de certificados dos Hypervisors)
Documento de procedimento interno da Nyverra Tecnologia, baseado em processo de Suporte de Infraestrutura, reestruturado para formato de artigo técnico.
Visão geral
O OLVM usa uma PKI interna própria para autenticar comunicação entre o Engine, os hosts (VDSM/libvirt), o console noVNC/SPICE, o OVN e outros componentes. Todos esses certificados têm validade limitada e, quando expiram, geram falhas de conexão silenciosas — hosts saem como "Não responsivo", consoles de VM parecem fora do ar, e logs mostram erros de handshake TLS.
Este guia documenta o processo completo de renovação, cobrindo quatro frentes que não acontecem automaticamente em conjunto:
As frentes 3 e 4 cobrem o mesmo tipo de certificado (host/VDSM), mas por caminhos diferentes: a frente 3 é o processo manual host-a-host; a frente 4 é o script oficial da Oracle que automatiza isso para um host, um cluster, ou todo o ambiente de uma vez. Use a frente 4 quando tiver vários hosts ou preferir o método suportado oficialmente.
Importante: este procedimento é para ambientes onde os certificados já expiraram. Se for uma renovação preventiva, o fluxo é o mesmo, mas o risco de indisponibilidade durante a execução é bem menor.
Antes de começar
-
Confirme se o Engine é \\standalone\\ ou \\self-hosted\\.
-
Se for self-hosted, ative o modo de manutenção primeiro, conforme Doc ID 3006292.1 (Oracle Support).
-
-
Garanta acesso root via SSH ou console.
-
Tenha uma janela de manutenção, pois alguns serviços reiniciam durante o processo.
-
Tenha espaço em disco suficiente para o backup (o \
engine-setup\também fará um backup interno do banco).
Etapa 1 — Backup do ambiente
Sempre rode o backup manual antes de iniciar, independente do backup que o engine-setup oferece fazer:
engine-backup --scope=all --mode=backup \
--file=/root/bkpcertificado.bck \
--log=/root/bkpcertificado.log
Isso garante um ponto de retorno completo (configuração + banco) caso algo saia do previsto.
Etapa 2 — Renovação via engine-setup
Inicie o processo:
engine-setup --offline
O assistente fará uma série de perguntas. Veja como responder cada uma:
Ao final, o engine-setup reinicia automaticamente os serviços do Engine (httpd, engine, dwh, websocket-proxy, grafana-server, etc.) e exibe um resumo com URLs de acesso e fingerprint SSH atualizado.
Nota: esse passo renova boa parte dos certificados, mas não todos. Alguns (OVN, vmconsole-proxy) ficam de fora e precisam da Etapa 4.
Etapa 3 — Verificando o que foi renovado
Liste a validade de todos os certificados do Engine:
cd /etc/pki/ovirt-engine/certs/
for cert in *.cer; do
echo "Certificate: $cert"
openssl x509 -in "$cert" -noout -dates
echo
done
Compare as datas notAfter — qualquer certificado ainda com data antiga (próxima ou já expirada) precisa de correção manual na próxima etapa. Tipicamente isso afeta:
-
ovirt-provider-ovn.cer -
ovn-ndb.cer -
ovn-sdb.cer -
vmconsole-proxy-helper.cer -
vmconsole-proxy-user.cer -
vmconsole-proxy-host.cer
Etapa 4 — Corrigindo certificados não renovados
4.1 Descubra o subject correto
Use um certificado válido existente como referência para manter o mesmo padrão de subject:
openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -subject
Exemplo de saída:
subject=C = US, O = exemplo.local, CN = olvm-mv-02.exemplo.local
4.2 Reemita os certificados pendentes
Com o subject em mãos, rode o script pki-enroll-pkcs12.sh para cada serviço pendente:
cd /etc/pki/ovirt-engine/certs
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="ovirt-provider-ovn" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="ovn-ndb" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="ovn-sdb" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="vmconsole-proxy-helper" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="vmconsole-proxy-user" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="vmconsole-proxy-host" --password=mypass \
--subject="/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" --keep-key
⚠️ Ajuste
--subjecte--passwordpara o seu ambiente. O subject deve refletir exatamente o domínio/FQDN do seu OLVM.
4.3 Reinicie os serviços afetados
systemctl restart ovirt-provider-ovn.service
systemctl restart ovn-northd.service
systemctl restart ovirt-vmconsole-proxy-sshd.service
Confirme que todos subiram com systemctl status antes de seguir.
Etapa 5 — Renovação do certificado VDSM
O certificado VDSM controla a comunicação Engine ↔ Host e também é reutilizado pelo SPICE/libvirt. Use o mesmo subject identificado na Etapa 4.1.
# 1. Gere o CSR a partir da chave existente
mkdir /root/vdsm
cd /etc/pki/vdsm/keys/
openssl req -new -key vdsmkey.pem -out /root/vdsm/vdsm.csr \
-passin "pass:mypass" -passout "pass:mypass" -batch -subj "/"
# 2. Assine o CSR com a CA interna do oVirt, válido por 10 anos
cd /etc/pki/ovirt-engine/
openssl ca -batch -policy policy_match -config openssl.conf \
-cert ca.pem -keyfile private/ca.pem -days +3650 \
-in /root/vdsm/vdsm.csr -out /root/vdsm/vdsm.cer \
-startdate "$(date --utc --date "now -1 days" +"%y%m%d%H%M%SZ")" \
-subj "/C=US/O=exemplo.local/CN=olvm-mv-02.exemplo.local" -utf8
# 3. Substitua o certificado VDSM (mantendo backup do antigo)
cd /etc/pki/vdsm/certs/
cp -a vdsmcert.pem vdsmcert.pem.old
cat /root/vdsm/vdsm.cer > vdsmcert.pem
# 4. Propague o novo certificado para SPICE e libvirt
cd /etc/pki/vdsm/libvirt-spice/
cp -a server-cert.pem server-cert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > server-cert.pem
cp -a /etc/pki/libvirt/clientcert.pem /etc/pki/libvirt/clientcert.pem.old
cat /etc/pki/vdsm/certs/vdsmcert.pem > /etc/pki/libvirt/clientcert.pem
# 5. Reinicie os serviços do host
systemctl restart libvirtd vdsmd
systemctl status libvirtd vdsmd
Confirme a nova validade:
openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -dates
O certificado deve agora expirar 10 anos no futuro (-days +3650), em vez do prazo padrão de 1 ano usado pelo engine-setup.
Etapa 6 — Renovando certificados dos Hypervisors com o script OlvmKvmCerts
A Oracle disponibiliza um script oficial, o OlvmKvmCerts, que automatiza a checagem e a renovação de certificados em um ou mais Hypervisors (KVM hosts) diretamente do Engine — sem precisar repetir manualmente os passos da Etapa 5 em cada host. É documentado no Doc ID 3008653.1 da Oracle Support.
Quando usar: ambientes com múltiplos hosts, ou quando o método manual (Etapa 5) já foi feito num host e você quer aplicar o mesmo resultado nos demais de forma rápida e auditável.
Quando NÃO usar como primeira opção: o método recomendado pela própria Oracle continua sendo colocar o host em manutenção e usar a opção "Enroll" do Admin Portal. O script é descrito oficialmente como uma "medida de emergência" para quando o certificado já expirou e o enroll preventivo não foi feito a tempo.
Compatibilidade: testado pela Oracle em OLVM 4.3, 4.4 e 4.5, em Oracle Linux 7.9 ou superior.
⚠️ Se o Engine também estiver com certificados expirados, renove-os primeiro (Etapas 1–5 / Doc ID 3006292.1) antes de rodar este script.
6.1 Download e preparação
Baixe a versão mais recente do script (anexa ao Doc ID 3008653.1) e copie para o Engine — o script só roda lá, nunca direto em um Hypervisor.
chmod 755 OlvmKvmCerts
chown root:root OlvmKvmCerts
6.2 Desabilite o Cluster Fencing antes de rodar
No Admin Portal do OLVM, desabilite o fencing do cluster antes de executar o script. O próprio script desabilita/reabilita o power management do host durante o processo, mas alguns hosts demoram a reportar o status correto — fencing ativo nesse intervalo pode causar reinício indesejado do host.
6.3 Comandos disponíveis
./OlvmKvmCerts
Usage: OlvmKvmCert [OPTION] <HOST|CLUSTER>
status Exibe o status de todos os certificados no Engine
list-hosts Lista todos os Hypervisors
renew-host <HOST> Renova os certificados de um único Hypervisor
renew-cluster <CLUSTER> Renova os certificados de todos os Hypervisors de um Cluster
renew-all Renova os certificados de todos os Hypervisors
check-host <HOST> Verifica todos os certificados de um único Hypervisor
check-cluster <CLUSTER> Verifica todos os certificados de todos os Hypervisors de um Cluster
check-all Verifica todos os certificados de todos os Hypervisors
6.4 Exemplos de uso
Ver a validade de todos os certificados do Engine:
./OlvmKvmCerts status
engine.cer Dec 15 10:23:05 2028 GMT
jboss.cer Dec 15 10:23:06 2028 GMT
websocket-proxy.cer Jan 16 10:23:06 2025 GMT
apache.cer Jan 16 10:23:06 2025 GMT
reports.cer Dec 15 10:23:06 2028 GMT
ovn-ndb.cer Dec 15 10:23:06 2028 GMT
ovn-sdb.cer Dec 15 10:23:07 2028 GMT
ovirt-provider-ovn.cer Dec 15 10:23:07 2028 GMT
vmconsole-proxy-helper.cer Dec 15 10:23:09 2028 GMT
vmconsole-proxy-user.cer Dec 15 10:23:09 2028 GMT
vmconsole-proxy-host.cer Dec 15 10:23:09 2028 GMT
hypervisor1.exemplo.local.cer Mar 6 16:53:36 2029 GMT
hypervisor2.exemplo.local.cer Mar 6 16:56:38 2029 GMT
Listar todos os hosts gerenciados:
./OlvmKvmCerts list-hosts
name | host | cluster
------------+------------------------+---------
hypervisor1 | hypervisor1.exemplo.local | Default
hypervisor2 | hypervisor2.exemplo.local | Default
Checar (sem alterar) os certificados de um host específico:
./OlvmKvmCerts check-host hypervisor1.exemplo.local
O script valida, host a host: conectividade, certificado e chave privada do VDSM, libvirt-migrate, libvirt-spice, libvirt-vnc e OVN — confirmando cada item com [PASS] ou apontando falha.
Renovar os certificados de um host:
./OlvmKvmCerts renew-host hypervisor2.exemplo.local
O script executa, nessa ordem, para o host informado:
-
Backup local dos certificados atuais
-
Geração de nova chave/CSR e assinatura pela CA do Engine (VDSM, libvirt, libvirt-spice, libvirt-vnc)
-
Cópia dos novos certificados para o host
-
Mesmo processo para o certificado OVN
-
Geração do certificado libvirt-migrate (quando aplicável à versão do OLVM)
-
Desabilita o power management do host, reinicia os serviços afetados, espera o host voltar para "Available" e reabilita o power management
6.5 Pós-execução
-
No Admin Portal, reabilite o Cluster Fencing caso tenha desabilitado no passo 6.2.
-
O script guarda um backup temporário dos certificados anteriores em
/var/tmpem cada host — útil para rollback manual caso algo dê errado (basta extrair, copiar os arquivos de volta para os caminhos originais e reiniciar os serviços). -
Mesmo após a renovação via script ser bem-sucedida, é recomendado, posteriormente, agendar uma manutenção e fazer o "Enroll" do host pelo Admin Portal — o script é uma correção de emergência, não substitui o fluxo oficial de longo prazo.
Histórico de correções do script (para referência)
Se, após a renovação, o console noVNC apresentar "Something went wrong, connection is closed" e o /var/log/messages mostrar erro de criptografia, ajuste as permissões da chave Apache e force o websocket-proxy a usar o certificado correto:
chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass
cp -a /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf \
/etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf
vim /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/99-setup.conf
Adicione (ou confirme) as linhas no arquivo 99-setup.conf:
SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass
Reinicie o serviço:
systemctl restart ovirt-websocket-proxy.service
Se ainda não funcionar: importe a CA como intermediária no navegador
-
Acesse, substituindo pelo FQDN do seu OLVM:
https://FQDN/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA -
Renomeie o arquivo baixado para extensão
.pem. -
No navegador (ex.: Chrome), importe esse
.pemem:
Configurações → Privacidade e segurança → Gerenciar certificados → Autoridades de Certificação Intermediárias → Importar
Isso resolve casos em que o browser ainda desconfia da nova cadeia de certificação mesmo com os serviços corretamente configurados.
Checklist final
-
Backup \
engine-backup\realizado e armazenado fora do servidor -
\
engine-setup --offline\concluído sem erros -
Todos os \
.cer\em \/etc/pki/ovirt-engine/certs/\com \notAfter\atualizado -
Certificados OVN e vmconsole-proxy reemitidos manualmente (se necessário)
-
Certificado VDSM renovado e propagado para SPICE/libvirt
-
\(Alternativa)\ Cluster Fencing desabilitado antes de rodar o \
OlvmKvmCerts\ -
\(Alternativa)\ \
OlvmKvmCerts check-all\ou \status\confirmando validade atualizada em todos os hosts -
\(Alternativa)\ Cluster Fencing reabilitado após o script
-
\(Alternativa)\ Hosts re-enrolados via Admin Portal após uso do script (boa prática pós-emergência)
-
Serviços \
ovirt-provider-ovn\, \ovn-northd\, \ovirt-vmconsole-proxy-sshd\, \libvirtd\, \vdsmd\ativos -
Console noVNC testado e funcional
-
Host validado como "Up" no painel do OLVM
Referências
-
Eclipsys — OLVM Renew Engine and KVM Certificate
-
Oracle Support — Doc ID 3006292.1 (modo de manutenção em ambiente self-hosted)
-
Oracle Support — Doc ID 2960024.1 (atualização de certificados não renovados pelo engine-setup)
-
Oracle Support — Doc ID 2922244.1 (importação de CA intermediária no navegador)
-
Oracle Support — Doc ID 3008653.1 (script
OlvmKvmCerts— checagem e renovação de certificados dos Hypervisors)
Documento de procedimento interno da Nyverra Tecnologia, baseado em processo de Suporte de Infraestrutura, reestruturado para formato de artigo técnico.
Continuar a ler
Leia também

iSCSI no TrueNAS: Guia Completo de Configuração e Gerenciamento
13 min de leitura
SegurançaCertificados SSL/TLS: Guia Completo de Geração e Conversão entre Formatos
Este guia técnico cobre a geração de certificados SSL/TLS com Certbot, conversão entre formatos PEM, PFX, DER e as melhores práticas de segurança para proteger chaves privadas e automatizar renovações. Inclui exemplos práticos de configuração para Nginx e Apache.
9 min de leitura
StorCLI - Cheat Sheet Completo
12 min de leitura
Comentários
Ainda sem comentários
Seja o primeiro a compartilhar sua opinião sobre este artigo.

Deixe um comentário