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