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