----- Original Message ----- > From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> > To: "John Ferlan" <jferlan@xxxxxxxxxx> > Cc: libvir-list@xxxxxxxxxx > Sent: Wednesday, December 18, 2013 3:57:22 PM > Subject: Re: [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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list