No será la primera vez, ni desgraciadamente la última, en la que nos encontremos que un servidor de Oracle VM que está registrado en Oracle VM Manager y que forma parte de un pool, con sus respectivas configuraciones, queda en un estado inconsistente o «huerfano«. Esto sucede cuando por ejemplo se elimina en Oracle VM Manager una configuración que hace referencia a ese servidor cuando este estaba inaccesible. Esto crea una inconsistencia entre la base de datos local que guarda el hipervisor con su agente (ovs-agent) y la que tiene el VM Manager.
A partir de la versión 2.3 (si no me equivoco) Oracle pone a nuestra disposición un script, cleanup.py, que se encarga de limpiar la base de datos local de ovs-agent:
/opt/ovs-agent-2.3/utils/cleanup.py
Hace lo siguiente:
- Para el servicio OCFS2 cluster (o2cb) heartbeat.
- Pone offline el servicio OCFS2 cluster (o2cb).
- Elimina la configuración de o2cb.
- Desmonta cualquier repo gestionado por el agente ovs-agent.
- Limpia la base de datos local de ovs-agent.
Ejemplo de ejecución:
# /opt/ovs-agent-2.3/utils/cleanup.py This is a cleanup script for ovs-agent. It will try to do the following: *) stop o2cb heartbeat *) offline o2cb *) remove o2cb configuration file *) umount ovs-agent storage repositories *) cleanup ovs-agent local database Would you like to continue? [y/N]
Si tenéis versiones inferiores a la 2.3. Podéis copiar el script de una versión superior y ejecutarlo, debería funcionar igual. Sino, siempre podéis ejecutar a mano estos pasos:
# service ovs-agent stop # rm /etc/ovs-agent/db # > /etc/ocfs2/cluster.conf # service ovs-agent start