----- Original Message -----
From: "Daniel P. Berrange" <berrange@redhat.com> To: "John Ferlan" <jferlan@redhat.com> Cc: libvir-list@redhat.com Sent: Wednesday, December 18, 2013 3:57:22 PM Subject: Re: [libvirt] [PATCH] Block info query: Add flag to allow failure if not active
On Wed, Dec 18, 2013 at 09:49:46AM -0500, John Ferlan wrote:
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.
But it must have a virDomainPtr instance, so it can use virDomainGetState() or virDomainIsActive() if it cares about this.
oVirt is using only transient domains, so it seems to me that the assumption here is that blockInfo should either return a value from a running qemu process or an error (because the domain doesn't exist anymore). Having a short moment where it's treated as a non-transient domain is confusing. It's fine by me if you want to maintain the current implementation for non-transient domains (and therefore the new flag is not needed).
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.
Sure, I agree that libvirt isn't ideal here - our hands are tied by the fact that QEMU doesn't make this data available to us offline. If we changed anything on the libvirt side, then I'd want to see us do a proper fix to get the data but that'd require qemu help;
I added the support for this to qemu-img. It scans a qcow2 image and reports the highest allocated cluster. Sadly the only way to implement it was on the image check (takes a long time). -- Federico