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 /etc/init/libvirt-bin.conf. > 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. Andreas [1] http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-lsb.html
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
