On 2013-05-03 15:07, Daniel P. Berrange wrote:
On Fri, May 03, 2013 at 10:10:50AM +0100, Daniel P. Berrange wrote:
On Fri, May 03, 2013 at 11:07:52AM +0200, Franky Van Liedekerke
wrote:
On 2013-05-03 10:51, Daniel P. Berrange wrote:
On Fri, May 03, 2013 at 10:39:33AM +0200, Franky Van Liedekerke
wrote:
Virtlockd
=========
Since sanlock was not working as expected, I tried virtlockd. This
seems to be working well, but: live migration fails because the
file
on the shared disk (used for locking) is being locked by the
original server running the VM. So when trying to do live
migration,
this fails and leaves the VM paused on the original server. Trying
to migrate a paused server then works ok, but that's of course not
live migration.
That would be a bug - the lock is suposed to be released on the
source & re-acquired on the dest at the switch-over point.
Daniel
Okay ... anyway to test/debug that? Any gfs2 options to take into
account? I can recompile virtlockd if wanted ...
It is unlikley to have anything todo with GFS2. It'll bug a bug
hiding
somewhere in the lock manager or QEMU code I expect. Some sequence of
operations is not quite right
A rather awful coding screwup caused us to never release locks when
the
VM was paused, thus breaking migration
The fix is here
https://www.redhat.com/archives/libvir-list/2013-May/msg00240.html
Daniel
I confirm that the fix seems to work. I need to test some more, but
it's looking good so far.
Franky
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
