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