On 1/31/2013 10:40 AM, Daniel P. Berrange wrote:
On Thu, Jan 31, 2013 at 10:35:17AM -0800, Michael Rodrigues wrote:
> Hi Daniel,
>
> I thought migration might be the reason, but I'm still not seeing
> the behavior you describe with regards to pausing. I saw the
> following behavior:
>
> 1. Created VM on node 1
> 2. Started VM on node 1
> 3. Migrated VM to node 2, node 1 is now shutdown, node 2 is running
> 4. I paused node 2
> 5. I started node 1, no error
> 6. Paused node 1
> 7. Unpaused node 2, no err
>
> I thought maybe the original VM had to be paused first, so I tried
> that as well:
>
> 1. Created VM on node 1
> 2. Started VM on node 1
> 3. Migrated to node 2, node 1 is now shutdown, node 2 is running
> 4. I shutdown node 2 instead of pausing
> 5. I started node 1
> 6. I paused node 1
> 7. Started node 2
> 8. Paused node 2
> 9. Started node 1
Hmm, that isn't supposed to be possible. When you paused node 1
in step 6, it was supposed to record the lease version number.
When you resume in step 9, the version number should mis-match
due to step 7, and thus sandlock ought to have caused an error
at step 9. If that didn't happen, then I believe we have a bug
Should I file a
report? I'm not really a developer but I can provide
whatever information is necessary for a proper report. I don't have RHEL
or a bugzilla account.
> So sanlock is preventing both from running concurrently, but it
> seems to contradict your statement:
> "Even if you now pause the VM on node 2, and try to resume node 1,
> sanlock will still prevent node 1 from running again. It tracks a
> lock "version" number. The key is that once the original VM is
> paused, if any other VM runs on that disk, the orignal VM is never
> allowed to be unpaused again."
Daniel
--
Michael Rodrigues
Interim Help Desk Manager
Gevirtz Graduate School of Education
Education Building 4203
(805) 893-8031
help(a)education.ucsb.edu