Renovación de Certificados en OLVM (Oracle Linux Virtualization Manager)

Versión probada: OLVM 4.4.10.7-1.0.18.el8
Frecuencia recomendada: anual (los certificados expiran en ~395 días)
Prerrequisito crítico: copia de seguridad completa antes de cualquier cambio

Visión general

OLVM utiliza una PKI interna propia para autenticar la comunicación entre el Engine, los hosts (VDSM/libvirt), la consola noVNC/SPICE, el OVN y otros componentes. Todos estos certificados tienen validez limitada y, cuando expiran, generan fallos de conexión silenciosos: los hosts aparecen como "No responde", las consolas de VM parecen no funcionar y los registros muestran errores de handshake TLS.

Esta guía documenta el proceso completo de renovación, cubriendo cuatro frentes que no ocurren automáticamente en conjunto:

Las frentes 3 y 4 cubren el mismo tipo de certificado (host/VDSM), pero por caminos diferentes: la frente 3 es el proceso manual host a host; la frente 4 es el script oficial de Oracle que automatiza esto para un host, un clúster o todo el entorno de una vez. Utilice la frente 4 cuando tenga varios hosts o prefiera el método soportado oficialmente.

Importante: este procedimiento es para entornos donde los certificados ya han expirado. Si es una renovación preventiva, el flujo es el mismo, pero el riesgo de indisponibilidad durante la ejecución es mucho menor.

Antes de comenzar

• Confirme si el Engine es standalone o self-hosted.

  • Si es self-hosted, active primero el modo de mantenimiento, según Doc ID 3006292.1 (Soporte Oracle).

• Garantice acceso root por SSH o consola.

• Disponga de una ventana de mantenimiento, ya que algunos servicios se reinician durante el proceso.

• Disponga de espacio en disco suficiente para la copia de seguridad (el engine-setup también realizará una copia de seguridad interna de la base de datos).

Paso 1 — Copia de seguridad del entorno

Siempre realice la copia de seguridad manual antes de comenzar, independientemente de la copia de seguridad que ofrece hacer el engine-setup:

engine-backup --scope=all --mode=backup \
  --file=/root/bkpcertificado.bck \
  --log=/root/bkpcertificado.log

Esto garantiza un punto de retorno completo (configuración + base de datos) en caso de que algo salga mal.

Paso 2 — Renovación mediante engine-setup

Inicie el proceso:

engine-setup --offline

El asistente hará una serie de preguntas. Vea cómo responder cada una:

Al final, el engine-setup reinicia automáticamente los servicios del Engine (httpd, engine, dwh, websocket-proxy, grafana-server, etc.) y muestra un resumen con URLs de acceso y huella SSH actualizada.

Nota: este paso renueva buena parte de los certificados, pero no todos. Algunos (OVN, vmconsole-proxy) quedan fuera y necesitan el Paso 4.

Paso 3 — Verificando lo que se ha renovado

Enumere la validez de todos los certificados del Engine:

cd /etc/pki/ovirt-engine/certs/
for cert in *.cer; do
  echo "Certificate: $cert"
  openssl x509 -in "$cert" -noout -dates
  echo
done

Compare las fechas notAfter; cualquier certificado que aún tenga una fecha antigua (próxima o ya expirada) necesita corrección manual en el siguiente paso. Normalmente esto afecta a:

• ovirt-provider-ovn.cer

• ovn-ndb.cer

• ovn-sdb.cer

• vmconsole-proxy-helper.cer

• vmconsole-proxy-user.cer

• vmconsole-proxy-host.cer

Paso 4 — Corrigiendo certificados no renovados

4.1 Descubra el subject correcto

Utilice un certificado válido existente como referencia para mantener el mismo patrón de subject:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -subject

Ejemplo de salida:

subject=C = US, O = exemplo.local, CN = olvm-mv-02.exemplo.local

4.2 Reemita los certificados pendientes

Con el subject a mano, ejecute el script pki-enroll-pkcs12.sh para cada servicio pendiente:

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 y --password para su entorno. El subject debe reflejar exactamente el dominio/FQDN de su OLVM.

4.3 Reinicie los servicios afectados

systemctl restart ovirt-provider-ovn.service
systemctl restart ovn-northd.service
systemctl restart ovirt-vmconsole-proxy-sshd.service

Confirme que todos se han iniciado con systemctl status antes de continuar.

Paso 5 — Renovación del certificado VDSM

El certificado VDSM controla la comunicación Engine ↔ Host y también es reutilizado por SPICE/libvirt. Utilice el mismo subject identificado en el Paso 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 la nueva validez:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -dates

El certificado ahora debe expirar 10 años en el futuro (-days +3650), en lugar del plazo estándar de 1 año utilizado por engine-setup.

Paso 6 — Renovando certificados de los Hypervisors con el script OlvmKvmCerts

Oracle proporciona un script oficial, OlvmKvmCerts, que automatiza la comprobación y renovación de certificados en uno o más Hypervisors (hosts KVM) directamente desde el Engine, sin necesidad de repetir manualmente los pasos del Paso 5 en cada host. Está documentado en el Doc ID 3008653.1 de Oracle Support.

Cuándo usar: entornos con múltiples hosts, o cuando el método manual (Paso 5) ya se ha realizado en un host y desea aplicar el mismo resultado a los demás de forma rápida y auditable.

Cuándo NO usar como primera opción: el método recomendado por la propia Oracle sigue siendo poner el host en mantenimiento y usar la opción "Enroll" del Admin Portal. El script se describe oficialmente como una "medida de emergencia" para cuando el certificado ya ha expirado y el enroll preventivo no se hizo a tiempo.

Compatibilidad: probado por Oracle en OLVM 4.3, 4.4 y 4.5, en Oracle Linux 7.9 o superior.

⚠️ Si el Engine también tiene certificados expirados, renuévelos primero (Pasos 1–5 / Doc ID 3006292.1) antes de ejecutar este script.

6.1 Descarga y preparación

Descargue la versión más reciente del script (adjunta al Doc ID 3008653.1) y cópiela en el Engine: el script solo se ejecuta allí, nunca directamente en un Hypervisor.

chmod 755 OlvmKvmCerts
chown root:root OlvmKvmCerts

6.2 Deshabilite el Cluster Fencing antes de ejecutar

En el Admin Portal de OLVM, deshabilite el fencing del clúster antes de ejecutar el script. El propio script deshabilita/rehabilita la administración de energía del host durante el proceso, pero algunos hosts tardan en reportar el estado correcto: el fencing activo en ese intervalo puede provocar un reinicio no deseado del host.

6.3 Comandos disponibles

./OlvmKvmCerts

Usage: OlvmKvmCert [OPTION] 

status                    Exibe o status de todos os certificados no Engine
list-hosts                Lista todos os Hypervisors
renew-host          Renova os certificados de um único Hypervisor
renew-cluster    Renova os certificados de todos os Hypervisors de um Cluster
renew-all                 Renova os certificados de todos os Hypervisors
check-host          Verifica todos os certificados de um único Hypervisor
check-cluster    Verifica todos os certificados de todos os Hypervisors de um Cluster
check-all                 Verifica todos os certificados de todos os Hypervisors

6.4 Ejemplos de uso

Ver la validez de todos los certificados del 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 los hosts gestionados:

./OlvmKvmCerts list-hosts

name        | host                   | cluster
------------+------------------------+---------
hypervisor1 | hypervisor1.exemplo.local | Default
hypervisor2 | hypervisor2.exemplo.local | Default

Comprobar (sin modificar) los certificados de un host específico:

./OlvmKvmCerts check-host hypervisor1.exemplo.local

El script valida, host por host: conectividad, certificado y clave privada de VDSM, libvirt-migrate, libvirt-spice, libvirt-vnc y OVN, confirmando cada elemento con [PASS] o señalando un fallo.

Renovar los certificados de un host:

./OlvmKvmCerts renew-host hypervisor2.exemplo.local

El script ejecuta, en este orden, para el host indicado:

1. Copia de seguridad local de los certificados actuales

2. Generación de nueva clave/CSR y firma por la CA del Engine (VDSM, libvirt, libvirt-spice, libvirt-vnc)

3. Copia de los nuevos certificados al host

4. Mismo proceso para el certificado OVN

5. Generación del certificado libvirt-migrate (cuando sea aplicable a la versión de OLVM)

6. Deshabilita la administración de energía del host, reinicia los servicios afectados, espera a que el host vuelva a estar "Available" y rehabilita la administración de energía

6.5 Post-ejecución

• En el Admin Portal, rehabilite el Cluster Fencing si lo deshabilitó en el paso 6.2.

• El script guarda una copia de seguridad temporal de los certificados anteriores en /var/tmp en cada host, útil para un rollback manual en caso de que algo salga mal (basta con extraer, copiar los archivos de vuelta a las rutas originales y reiniciar los servicios).

• Aun después de que la renovación mediante script sea exitosa, se recomienda posteriormente programar un mantenimiento y realizar el "Enroll" del host desde el Admin Portal: el script es una corrección de emergencia, no sustituye el flujo oficial a largo plazo.

Historial de correcciones del script (para referencia)

Si, después de la renovación, la consola noVNC muestra "Something went wrong, connection is closed" y el /var/log/messages muestra un error de cifrado, ajuste los permisos de la clave de Apache y fuerce al websocket-proxy a usar el certificado correcto:

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

Agregue (o confirme) las líneas en el archivo 99-setup.conf:

SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass

Reinicie el servicio:

systemctl restart ovirt-websocket-proxy.service

Si aún no funciona: importe la CA como intermedia en el navegador

1. Acceda, reemplazando por el FQDN de su OLVM:

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

2. Renombre el archivo descargado con la extensión .pem.

3. En el navegador (p. ej., Chrome), importe ese .pem en:
   Configuración → Privacidad y seguridad → Gestionar certificados → Autoridades de certificación intermedias → Importar

Esto resuelve los casos en los que el navegador aún desconfía de la nueva cadena de certificación aunque los servicios estén correctamente configurados.

Lista de verificación final

• Copia de seguridad engine-backup realizada y almacenada fuera del servidor

• engine-setup --offline completado sin errores

• Todos los .cer en /etc/pki/ovirt-engine/certs/ con notAfter actualizado

• Certificados OVN y vmconsole-proxy reemitidos manualmente (si es necesario)

• Certificado VDSM renovado y propagado a SPICE/libvirt

• (Alternativa) Cluster Fencing deshabilitado antes de ejecutar OlvmKvmCerts

• (Alternativa) OlvmKvmCerts check-all o status confirmando validez actualizada en todos los hosts

• (Alternativa) Cluster Fencing rehabilitado después del script

• (Alternativa) Hosts re-inscritos (enroll) mediante Admin Portal después del uso del script (buena práctica post-emergencia)

• Servicios ovirt-provider-ovn, ovn-northd, ovirt-vmconsole-proxy-sshd, libvirtd, vdsmd activos

• Consola noVNC probada y funcional

• Host validado como "Up" en el panel de OLVM

Referencias

• Eclipsys — OLVM Renew Engine and KVM Certificate

• Soporte Oracle — Doc ID 3006292.1 (modo de mantenimiento en entorno self-hosted)

• Soporte Oracle — Doc ID 2960024.1 (actualización de certificados no renovados por engine-setup)

• Soporte Oracle — Doc ID 2922244.1 (importación de CA intermedia en el navegador)

• Soporte Oracle — Doc ID 3008653.1 (script OlvmKvmCerts — comprobación y renovación de certificados de los Hypervisors)

Documento de procedimiento interno de Nyverra Tecnologia, basado en proceso de Soporte de Infraestructura, reestructurado para formato de artículo técnico.

Visión general

OLVM utiliza una PKI interna propia para autenticar la comunicación entre el Engine, los hosts (VDSM/libvirt), la consola noVNC/SPICE, el OVN y otros componentes. Todos estos certificados tienen validez limitada y, cuando expiran, generan fallos de conexión silenciosos: los hosts aparecen como "No responde", las consolas de VM parecen no funcionar y los registros muestran errores de handshake TLS.

Esta guía documenta el proceso completo de renovación, cubriendo cuatro frentes que no ocurren automáticamente en conjunto:

Las frentes 3 y 4 cubren el mismo tipo de certificado (host/VDSM), pero por caminos diferentes: la frente 3 es el proceso manual host a host; la frente 4 es el script oficial de Oracle que automatiza esto para un host, un clúster o todo el entorno de una vez. Utilice la frente 4 cuando tenga varios hosts o prefiera el método soportado oficialmente.

Importante: este procedimiento es para entornos donde los certificados ya han expirado. Si es una renovación preventiva, el flujo es el mismo, pero el riesgo de indisponibilidad durante la ejecución es mucho menor.

Antes de comenzar

• Confirme si el Engine es standalone o self-hosted.

  • Si es self-hosted, active primero el modo de mantenimiento, según Doc ID 3006292.1 (Soporte Oracle).

• Garantice acceso root por SSH o consola.

• Disponga de una ventana de mantenimiento, ya que algunos servicios se reinician durante el proceso.

• Disponga de espacio en disco suficiente para la copia de seguridad (el engine-setup también realizará una copia de seguridad interna de la base de datos).

Paso 1 — Copia de seguridad del entorno

Siempre realice la copia de seguridad manual antes de comenzar, independientemente de la copia de seguridad que ofrece hacer el engine-setup:

engine-backup --scope=all --mode=backup \
  --file=/root/bkpcertificado.bck \
  --log=/root/bkpcertificado.log

Esto garantiza un punto de retorno completo (configuración + base de datos) en caso de que algo salga mal.

Paso 2 — Renovación mediante engine-setup

Inicie el proceso:

engine-setup --offline

El asistente hará una serie de preguntas. Vea cómo responder cada una:

Al final, el engine-setup reinicia automáticamente los servicios del Engine (httpd, engine, dwh, websocket-proxy, grafana-server, etc.) y muestra un resumen con URLs de acceso y huella SSH actualizada.

Nota: este paso renueva buena parte de los certificados, pero no todos. Algunos (OVN, vmconsole-proxy) quedan fuera y necesitan el Paso 4.

Paso 3 — Verificando lo que se ha renovado

Enumere la validez de todos los certificados del Engine:

cd /etc/pki/ovirt-engine/certs/
for cert in *.cer; do
  echo "Certificate: $cert"
  openssl x509 -in "$cert" -noout -dates
  echo
done

Compare las fechas notAfter; cualquier certificado que aún tenga una fecha antigua (próxima o ya expirada) necesita corrección manual en el siguiente paso. Normalmente esto afecta a:

• ovirt-provider-ovn.cer

• ovn-ndb.cer

• ovn-sdb.cer

• vmconsole-proxy-helper.cer

• vmconsole-proxy-user.cer

• vmconsole-proxy-host.cer

Paso 4 — Corrigiendo certificados no renovados

4.1 Descubra el subject correcto

Utilice un certificado válido existente como referencia para mantener el mismo patrón de subject:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -subject

Ejemplo de salida:

subject=C = US, O = exemplo.local, CN = olvm-mv-02.exemplo.local

4.2 Reemita los certificados pendientes

Con el subject a mano, ejecute el script pki-enroll-pkcs12.sh para cada servicio pendiente:

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 y --password para su entorno. El subject debe reflejar exactamente el dominio/FQDN de su OLVM.

4.3 Reinicie los servicios afectados

systemctl restart ovirt-provider-ovn.service
systemctl restart ovn-northd.service
systemctl restart ovirt-vmconsole-proxy-sshd.service

Confirme que todos se han iniciado con systemctl status antes de continuar.

Paso 5 — Renovación del certificado VDSM

El certificado VDSM controla la comunicación Engine ↔ Host y también es reutilizado por SPICE/libvirt. Utilice el mismo subject identificado en el Paso 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 la nueva validez:

openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -noout -dates

El certificado ahora debe expirar 10 años en el futuro (-days +3650), en lugar del plazo estándar de 1 año utilizado por engine-setup.

Paso 6 — Renovando certificados de los Hypervisors con el script OlvmKvmCerts

Oracle proporciona un script oficial, OlvmKvmCerts, que automatiza la comprobación y renovación de certificados en uno o más Hypervisors (hosts KVM) directamente desde el Engine, sin necesidad de repetir manualmente los pasos del Paso 5 en cada host. Está documentado en el Doc ID 3008653.1 de Oracle Support.

Cuándo usar: entornos con múltiples hosts, o cuando el método manual (Paso 5) ya se ha realizado en un host y desea aplicar el mismo resultado a los demás de forma rápida y auditable.

Cuándo NO usar como primera opción: el método recomendado por la propia Oracle sigue siendo poner el host en mantenimiento y usar la opción "Enroll" del Admin Portal. El script se describe oficialmente como una "medida de emergencia" para cuando el certificado ya ha expirado y el enroll preventivo no se hizo a tiempo.

Compatibilidad: probado por Oracle en OLVM 4.3, 4.4 y 4.5, en Oracle Linux 7.9 o superior.

⚠️ Si el Engine también tiene certificados expirados, renuévelos primero (Pasos 1–5 / Doc ID 3006292.1) antes de ejecutar este script.

6.1 Descarga y preparación

Descargue la versión más reciente del script (adjunta al Doc ID 3008653.1) y cópiela en el Engine: el script solo se ejecuta allí, nunca directamente en un Hypervisor.

chmod 755 OlvmKvmCerts
chown root:root OlvmKvmCerts

6.2 Deshabilite el Cluster Fencing antes de ejecutar

En el Admin Portal de OLVM, deshabilite el fencing del clúster antes de ejecutar el script. El propio script deshabilita/rehabilita la administración de energía del host durante el proceso, pero algunos hosts tardan en reportar el estado correcto: el fencing activo en ese intervalo puede provocar un reinicio no deseado del host.

6.3 Comandos disponibles

./OlvmKvmCerts

Usage: OlvmKvmCert [OPTION] 

status                    Exibe o status de todos os certificados no Engine
list-hosts                Lista todos os Hypervisors
renew-host          Renova os certificados de um único Hypervisor
renew-cluster    Renova os certificados de todos os Hypervisors de um Cluster
renew-all                 Renova os certificados de todos os Hypervisors
check-host          Verifica todos os certificados de um único Hypervisor
check-cluster    Verifica todos os certificados de todos os Hypervisors de um Cluster
check-all                 Verifica todos os certificados de todos os Hypervisors

6.4 Ejemplos de uso

Ver la validez de todos los certificados del 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 los hosts gestionados:

./OlvmKvmCerts list-hosts

name        | host                   | cluster
------------+------------------------+---------
hypervisor1 | hypervisor1.exemplo.local | Default
hypervisor2 | hypervisor2.exemplo.local | Default

Comprobar (sin modificar) los certificados de un host específico:

./OlvmKvmCerts check-host hypervisor1.exemplo.local

El script valida, host por host: conectividad, certificado y clave privada de VDSM, libvirt-migrate, libvirt-spice, libvirt-vnc y OVN, confirmando cada elemento con [PASS] o señalando un fallo.

Renovar los certificados de un host:

./OlvmKvmCerts renew-host hypervisor2.exemplo.local

El script ejecuta, en este orden, para el host indicado:

1. Copia de seguridad local de los certificados actuales

2. Generación de nueva clave/CSR y firma por la CA del Engine (VDSM, libvirt, libvirt-spice, libvirt-vnc)

3. Copia de los nuevos certificados al host

4. Mismo proceso para el certificado OVN

5. Generación del certificado libvirt-migrate (cuando sea aplicable a la versión de OLVM)

6. Deshabilita la administración de energía del host, reinicia los servicios afectados, espera a que el host vuelva a estar "Available" y rehabilita la administración de energía

6.5 Post-ejecución

• En el Admin Portal, rehabilite el Cluster Fencing si lo deshabilitó en el paso 6.2.

• El script guarda una copia de seguridad temporal de los certificados anteriores en /var/tmp en cada host, útil para un rollback manual en caso de que algo salga mal (basta con extraer, copiar los archivos de vuelta a las rutas originales y reiniciar los servicios).

• Aun después de que la renovación mediante script sea exitosa, se recomienda posteriormente programar un mantenimiento y realizar el "Enroll" del host desde el Admin Portal: el script es una corrección de emergencia, no sustituye el flujo oficial a largo plazo.

Historial de correcciones del script (para referencia)

Si, después de la renovación, la consola noVNC muestra "Something went wrong, connection is closed" y el /var/log/messages muestra un error de cifrado, ajuste los permisos de la clave de Apache y fuerce al websocket-proxy a usar el certificado correcto:

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

Agregue (o confirme) las líneas en el archivo 99-setup.conf:

SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass

Reinicie el servicio:

systemctl restart ovirt-websocket-proxy.service

Si aún no funciona: importe la CA como intermedia en el navegador

1. Acceda, reemplazando por el FQDN de su OLVM:

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

2. Renombre el archivo descargado con la extensión .pem.

3. En el navegador (p. ej., Chrome), importe ese .pem en:
   Configuración → Privacidad y seguridad → Gestionar certificados → Autoridades de certificación intermedias → Importar

Esto resuelve los casos en los que el navegador aún desconfía de la nueva cadena de certificación aunque los servicios estén correctamente configurados.

Lista de verificación final

• Copia de seguridad engine-backup realizada y almacenada fuera del servidor

• engine-setup --offline completado sin errores

• Todos los .cer en /etc/pki/ovirt-engine/certs/ con notAfter actualizado

• Certificados OVN y vmconsole-proxy reemitidos manualmente (si es necesario)

• Certificado VDSM renovado y propagado a SPICE/libvirt

• (Alternativa) Cluster Fencing deshabilitado antes de ejecutar OlvmKvmCerts

• (Alternativa) OlvmKvmCerts check-all o status confirmando validez actualizada en todos los hosts

• (Alternativa) Cluster Fencing rehabilitado después del script

• (Alternativa) Hosts re-inscritos (enroll) mediante Admin Portal después del uso del script (buena práctica post-emergencia)

• Servicios ovirt-provider-ovn, ovn-northd, ovirt-vmconsole-proxy-sshd, libvirtd, vdsmd activos

• Consola noVNC probada y funcional

• Host validado como "Up" en el panel de OLVM

Referencias

• Eclipsys — OLVM Renew Engine and KVM Certificate

• Soporte Oracle — Doc ID 3006292.1 (modo de mantenimiento en entorno self-hosted)

• Soporte Oracle — Doc ID 2960024.1 (actualización de certificados no renovados por engine-setup)

• Soporte Oracle — Doc ID 2922244.1 (importación de CA intermedia en el navegador)

• Soporte Oracle — Doc ID 3008653.1 (script OlvmKvmCerts — comprobación y renovación de certificados de los Hypervisors)

Documento de procedimiento interno de Nyverra Tecnologia, basado en proceso de Soporte de Infraestructura, reestructurado para formato de artículo técnico.