Re: [libvirt] [PATCH] Block info query: Add flag to allow failure if not active
----- Original Message -----
From: "Daniel P. Berrange" <berrange(a)redhat.com>
To: "John Ferlan" <jferlan(a)redhat.com>
Cc: libvir-list(a)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