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