On Thu, Oct 06, 2016 at 15:51:38 -0500, Eric Blake wrote: > On 10/06/2016 10:06 AM, Kashyap Chamarthy wrote: > > On Thu, Oct 06, 2016 at 09:25:26AM -0500, Eric Blake wrote: > >> On 10/06/2016 06:34 AM, Peter Krempa wrote: > > > > [...] > > > >>> We expose the state of the copy job in the XML and forward the READY > >>> event from qemu to the users. > >> > >> I was not aware of that when I was chatting on IRC yesterday; that's > >> useful to know, because virDomainGetBlockJobInfo() is NOT exposing that > >> information at the moment. > > > > That is what this RFC was asking to consider -- whether an [I think it > > has to be a new one] API should report. > > I think we've answered this one - we don't need a new API, because > parsing the domain XML already provides the current 'ready':true/false > status from qemu. > > The existing virDomainGetBlockJobInfo() can't be extended, but it can be > fixed to quit reporting cur==end when ready:false. Yes, I agree about this one (although I don't really like it [1]), but this one will actually fix software not listening for events without any change. Any new API would not help since the apps would need to change anyways thus can use the current correct approach right away even with older libvirt versions. Peter [1]: I'm expecting users to start complaining: "Why is this last byte of my image taking so long to copy after the rest copied pretty quickly".
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list