[Pacemaker] Clone Set does not start its lsb service on all nodes

Andreas Ntaflos daff at pseudoterminal.org
Wed Feb 15 17:09:53 EST 2012

On 2012-02-13 23:29, Andrew Martin wrote:
> However, often the libvirt-bin daemon is not actually running (and thus
> the VMs fail to migrate):
> # service libvirt-bin status
> libvirt-bin stop/waiting

It seems the libvirt init script (which is actually an upstart job)
either starts the daemon successfully and at some later point the daemon
itself fails, or the init script doesn't actually start the libvirt
daemon, even though it reports that it did.

What happens when you start libvirt manually by means of the init script
(after disabling the cluster or putting it into maintenance mode)? What
does /var/log/libvirt/libvirtd.log say?

Please also do the tests described in [1] to determine whether the
libvirt init script/upstart job behaves according to LSB specifications.

Also, to avoid any interferenc, you have to take care that only
pacemaker and not upstart has full control over starting and stopping
the libvirt daemon, i.e. making sure libvirt isn't started on system
startup. Usually this is done by means of update-rc.d, but this doesn't
work with upstart jobs. For Ubuntu 10.04 it means commenting the "start
on ..." and possibly "stop on ..." lines at the beginning of

> This does not seem like the correct behavior for the clone - my
> understanding is that a clone requires the resource to be running at all
> nodes at all times. What can I try to ensure that libvirt-bin remains
> running on all nodes?

I don't think pacemaker is the problem here. It seems more like your
libvirt daemons are misbehaving.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20120215/6779ffdd/attachment-0003.sig>

More information about the Pacemaker mailing list