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-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 --subject e --password para 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:

2. Backup local dos certificados atuais

4. Geração de nova chave/CSR e assinatura pela CA do Engine (VDSM, libvirt, libvirt-spice, libvirt-vnc)

6. Cópia dos novos certificados para o host

8. Mesmo processo para o certificado OVN

10. Geração do certificado libvirt-migrate (quando aplicável à versão do OLVM)

12. 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/tmp em 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

2. Acesse, substituindo pelo FQDN do seu OLVM:

    https://FQDN/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

4. Renomeie o arquivo baixado para extensão .pem.

6. No navegador (ex.: Chrome), importe esse .pem em:
   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.

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 --subject e --password para 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:

1. Backup local dos certificados atuais

2. Geração de nova chave/CSR e assinatura pela CA do Engine (VDSM, libvirt, libvirt-spice, libvirt-vnc)

3. Cópia dos novos certificados para o host

4. Mesmo processo para o certificado OVN

5. Geração do certificado libvirt-migrate (quando aplicável à versão do OLVM)

6. 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/tmp em 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

1. Acesse, substituindo pelo FQDN do seu OLVM:

    https://FQDN/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

2. Renomeie o arquivo baixado para extensão .pem.

3. No navegador (ex.: Chrome), importe esse .pem em:
   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.