Continue riallocazioni delle VM

Risolti i problemi di cui al post precedente, adesso il cluster con RedHat Cluster Suite e libvirt funziona alla grande.
Così alla grande che ogni due minuti le VM vengono riallocate, quelle che erano sull'host1 finiscono nell'host2 e viceversa. E mi raccomando, non migrate, riallocate.

Nei log questo simpatico errorino:

Jul 19 17:25:21 rgmanager status on vm "prometeo" returned 127 (unspecified)
Jul 19 17:25:21 rgmanager No other nodes have seen vm:prometeo

Criptico come poche volte, no? Come si risolve un problema del genere?

Provo a testare con rg_test:

# rg_test test /etc/cluster/cluster.conf status vm prometeo
...
Hypervisor URI: qemu:///system
Migration URI format: qemu+ssh://target_host/system
Virtual machine prometeo is running
Status check of prometeo failed

Coerente, direi. Quindi c'è un errore nel check dello status. Lo script inciminato è /usr/share/cluster/vm.sh, che usa due funzioni per verificare lo status, virsh_status e do_status (ci sarebbe anche xm_status, ma in questo momento non ci interessa):

virsh_status()
{
        declare state pid

        if [ "$OCF_RESKEY_hypervisor" = "xen" ]; then
                service xend status &> /dev/null
                if [ $? -ne 0 ]; then 
                        echo indeterminate
                        return $OCF_APP_ERR_INDETERMINATE
                fi
        fi

        #
        # libvirtd is required when using virsh even though
        # not specifically when also using Xen.  This is because
        # libvirtd is required for migration.
        #
        pid=$(pidof libvirtd)
        if [ -z "$pid" ]; then 
                echo indeterminate
                return $OCF_APP_ERR_INDETERMINATE
        fi

        state=$(virsh domstate $OCF_RESKEY_name)

        echo $state

        if [ "$state" = "running" ] || [ "$state" = "paused" ] ||
           [ "$state" = "no state" ] || 
           [ "$state" = "idle" ]; then
                return 0
        fi

        if [ "$state" = "shut off" ]; then
                return $OCF_NOT_RUNNING
        fi

        return $OCF_ERR_GENERIC
}


#
# Simple status check: Find the VM in the list of running
# VMs
#
do_status()
{
        if [ "$OCF_RESKEY_use_virsh" = "1" ]; then
                virsh_status
                return $?
        fi

        xm_status
        return $?
}

Guardatele quanto volete, l'errore non è in nessuna delle due funzioni: se la VM è viva, virsh_status ritorna 0 e do_status pure (era dura visto che non fa altro che richiamare virsh_status).

Dov'è il problema? Si verifica più avanti, per la precisione nel case che decide quale azione è stata richiamata:

status|monitor)
                validate_all || exit $OCF_ERR_ARGS
                echo -n "Virtual machine $OCF_RESKEY_name is "
                do_status
                rv=$?
                if [ $rv -ne 0 ]; then
                        exit $rv
                fi
                [ -z "$OCF_RESKEY_status_program" ] && exit 0
                [ -z "$OCF_CHECK_LEVEL" ] && exit 0
                [ $OCF_CHECK_LEVEL -lt 10 ] && exit 0

                bash -c "$OCF_RESKEY_status_program" &> /dev/null
                exit $?
                ;;

Qual è il problema? Il valore di status_program (uno dei parametri di configurazione della risorsa vm) di default è 0. Non vuoto (cosa che gli farebbe passare indenne il test in rosso e quindi farebbe uscire vm.sh), ma 0.

<parameter name="status_program" reconfig="1">
    <longdesc lang="en">
        Ordinarily, only the presence/health of a virtual machine
        is checked.  If specified, the status_program value is
        executed during a depth 10 check.  The intent of this 
        program is to ascertain the status of critical services
        within a virtual machine.
    </longdesc>
    <shortdesc lang="en">
        Additional status check program
    </shortdesc>
    <content type="string" default="0"/>

</parameter> 

A questo punto, salutati i santi che uno ha tirato giù dal Paradiso, la soluzione è aggiungere l'ennesimo parametro alla configurazione della VM in /etc/cluster/cluster.conf:

<vm autostart="0" domain="domainseminole" exclusive="0" migrate="live" 
    status_program="" name="prometeo" 
    xmlfile="/etc/libvirt/qemu/prometeo.xml" recovery="relocate"/>

(libvirt) Timed out during operation: cannot acquire state change lock

Bell'errore di stamattina, durante un tentativo di migrazione di una VM da un host all'altro.
Sembra che il problema sia un non meglio identificato bug di libvirt versione 0.8, e sembra che sparisca dalla 0.9:

https://bugzilla.redhat.com/show_bug.cgi?id=676205

Ma per chi come me è su una Debian Squeeze e non ha voglia di iniziare la trafila del backport dei pacchetti a neanche due mesi dall'aggiornamento, non è che sia di molta consolazione.
Comunque a quello che ho visto è un qualcosa che manda a funghi libvirt. Il sintomo principale non è tanto il messaggio del titolo, quanto che libvirt non dà più la situazione corretta. Per verificarlo basta vedere la dissonanza tra:

# virsh --connect qemu:///system list --all

e

# ps -elf | grep qemu

Dei due, è il secondo che ha ragione.

La soluzione è stata riavviare libvirt, ma se in uno dei due server la cosa è andata liscia con

# /etc/init.d/libvirt-bin restart

l'altro non voleva saperne di morire. Quindi:

# kill -9 <piddilibvirt>

(sì, ok, andava bene anche pkill libvirt-bin).

Restano un processo nc (netcat, che si individua con ps -elf | grep libvirt), anche quello da killare, e due socket: /var/run/libvirt-sock e /var/run/libvirt-sock-ro, entrambi da cancellare.

A questo punto, riavviato libvirtd, la situazione è allineata e la migrazione funziona. Per la cronaca, via ssh con:

# virsh --connect qemu:///system migrate --live <vm> qemu+ssh://<altro>/system