Success Tucker. I am also working on snapshot support on the libvirt xenlight driver as part of GSoC On Tue, May 20, 2014 at 7:40 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > On 05/20/2014 09:03 AM, Tucker DiNapoli wrote: >> Hello everyone, >> My name is Tucker DiNapoli and I'm going to be working on libvirt this >> summer for the google summer of code. My project is to implement job >> control in the storage driver. In order to do that I am first going to >> create a unified api for job control in libvirt (as it is currently >> implemented seperately in both the qemu and libxl drivers). I'm currently >> working on the api for job control and I have some ideas that I'll post on >> the mailing list soon. If anyone has any ideas or requests re job control >> I'd be happy to hear them. I'm on the #virt irc channel as tuckerD, I look >> forward to working on libvrt this summer. > > Welcome! I definitely have some ideas on the matter: > > https://www.redhat.com/archives/libvir-list/2014-February/msg01128.html > > and in notes I've taken from off-list communications: > >>> For that matter, we need to overhaul the job support. Right now, >>> virDomainBlockJob* assumes you can only have one outstanding job at a >>> time, which interferes with the notion of running fleecing from two >>> points in time. Similarly, there can only be one virDomainGetJobInfo >>> active. What we really need is a notion of a job id, a way to query the >>> job id most recently created by any existing job-related API, and a way >>> to query job status based on id rather than only the most-recently >>> started job. > > I'd _really_ like to see a common notion of a 'job id' that EVERY job > (whether domain-level, like migration; or block-level, like > commit/pull/rebase; or storage-level, like your new proposed storage > jobs) shares a common job namespace. The job id is a positive integer. > Existing APIs will have to be retrofitted into the new job id notion; > any action that starts a long-running job that currently returns 0 on > success could be changed to return a positive job id; or we may need a > new API that queries the notion of the 'current job' (the job most > recently started) or even to set the 'current job' to a different job > id. We'll need new API for querying a job by id, and to be most > portable, we should do job reporting via virTypedParameter > (virDomainGetJobInfo and virDomainGetBlockJobInfo are hardcoded into > returning a struct, so they are non-extensible; virDomainGetJobStats > almost did it right, except that the user has to call it twice, once to > learn how large to allocate, and again to pass in pre-allocated memory - > the ideal API would allocate the memory on a single call). > > The fact that many jobs are exclusive (only one domain job at a time, > and only one block job per disk) is currently inherent in the design of > not having a job id; but we eventually WANT to allow parallel jobs. So > I'm looking forward to reviewing your proposals. > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list