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@xxxxxxxxxxxxxxxxxx
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
