[libvirt] [PATCH] Block info query: Add flag to allow failure if not active

[Federico Simoncelli]

----- Original Message -----
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "John Ferlan" <jferlan at redhat.com>
> Cc: libvir-list at 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