On 2013-05-03 11:10, 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
Daniel
I'm seeing this on the source host when doing a live migration:
error : virLockSpaceAcquireResource:662 : resource busy Lockspace
resource
'86f38e27a48275cc2b1a1e12897ba0339875d5b005e68fe1f7d4a1ac038ccdb3' is
locked
and this on the destination:
error : virLockSpaceResourceNew:168 : resource busy Lockspace resource
'86f38e27a48275cc2b1a1e12897ba0339875d5b005e68fe1f7d4a1ac038ccdb3' is
locked
So ... any c-code tips? Or should I just not use virtlockd?
Franky
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
