[Libvirt-cim] [PATCH 3 of 6] 1) Added support for KVM
Kaitlin Rupert
kaitlin at linux.vnet.ibm.com
Thu Jul 31 16:02:20 UTC 2008
>>> +
>>> + # try to suspend already suspended VS
>>> + rq_state = SUSPND_STATE
>>> + status = try_request_state_change(default_dom, server,
>>> + rq_state, TIME, err_no, + err_desc, virt)
>>
>> I'm not sure I see the benefit of this change. You're not verifying
>> the state of the guest.
>>
>> It's possible for RequestStateChange() to return a success and for the
>> guest to be in an unexpected state.
> This particular test case was previously written with the assumption
> that moving an already suspended VS to suspend state will not return any
> exception from the provider and is a valid state transition. But this is
> not true anymore. Also, the the above test case used to XFAIL sometime
> back because of the problem in RequestedStateChange() bug.
> The provider now returns an exception when we try to suspend the VS
> which is already in suspended state. The exception is checked in the
> try_request_state_change() library function.
> The part of the code in the loop which we execute is not suppose to
> return any exception. Hence the code in the loop and the one in
> try_request_state_change() cannot be combined together.
> Regarding validating the req_state value after
> try_request_state_change() can be done to make sure the state still
> remains the same as it was in before calling the RequestStateChange().
I was thinking that all of the calls to RSC() should be handled the same
way - because any call to RSC() could potentially cause an exception or
an error.
But in the case where you call suspend twice in a row, you don't have an
easy way of distinguishing between the first suspend call and the
second. So my logic fails here. You need some way to distinguish the
two calls, and this works in that case.
So I'm fine with this approach. ;)
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com
More information about the Libvirt-cim
mailing list