On 12/18/2013 09:35 AM, Daniel P. Berrange wrote:
On Wed, Dec 18, 2013 at 06:58:10AM -0500, John Ferlan wrote:
I'm not convinced this flag is desirable. Can't apps just
check whether the guest is running themselves, or indeed
something like RHEV surely knows what its own VM is doing
already.
I do agree with you and that's been my argument in the referenced BZ;
however, as I understand it - they have a thread that continually polls
for blockInfo information and a separate thread that handles the
migration. The blockInfo thread doesn't have the state information.
I contend it's just as simple to add a check about the domain state and
to get/check the reason value as well. That is - I think the blockInfo
thread should be more aware of state. Of course, the return argument is
that libvirt shouldn't return different answers on consecutive fetches
where the first fetch is when the guest is "active" and the second is
when it's not.
To be honest this feels a bit hackish and it requires a deliberate
change to their code to not only provide the flag, but handle the error.
Since they'd already be changing their code to handle this, then why not
change to check state. There is a downside to their checking state
though and that's a timing condition where their check could indicate
the guest was active, but the "next clock tick" it becomes inactive.
Thus, their code would be in the same position of getting what is felt
is the wrong answer.
I figure opening it up to community discussion will help "decide" one
way or another the best approach.
I'm all for adjusting the documentation and leaving the code the way it
is now as well.
John