RFC: PATCH 0/5: asynchronous background jobs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We currently have a restriction that virConnectPtr objects
must only be used by a single thread. At the same time we
have a number of operations that can take a very long time.
This means that applications are pretty much forced to use
multi-threading if they want to continue to respond to user
input, and thus are also forced to use multiple virConnectPtr
objects.

This is sub-optimal because opening multiple virConnectPtr
objects may well result in the user being prompted for auth
credentials multiple times. It also doesn't provide any way
of providing progess information on the long running jobs,
nor a way to cancel them.

Thus the following series of patches introduces the concept of
an 'asynchronous background job', represented by a virJobPtr
object in the libvirt public API.

A job has an elapsed time, and may optionally include an
estimated time of completion. If it is a job with a bounded
amount of work, it will also have a percentage completion
counter. There is the ability to request cancellation of an
in progress job, and fetch any error associated with a
completed job.

The primary reason I implemented this support, is that the
storage APIs will make the current situation untennable.
Allocating storage can take a seriously long time (many
many minutes if cloning multi-GB files). This absolutely
requires progress information and an ability to cancel
an operation.

There are a number of existing APIs which can benefit from
this, hence I decided to work on this separately from the
main storage APIs. The APIs which can make use of this are
virDomainCreateLinux, virDomainCreate, virNetworkCreate,
virNetworkCreateXML, virDomainSave, virDomainRestore, and
virDomainDumpCore. For all of these we add a second variant
postfixed with 'Job' in the name, returning a virJobPtr object

This work isn't finished, but I wanted to put these patches
out for comment before going further. In particular I need
to figure out how to hook this up to the remote driver and
daemon, and deal with a few lifecycle issues. eg what todo
if a virConnectPtr object is released while a background job
is active.


With all 5 patches applied you should be able to run the
following test case:

  virsh --connect test:///default save --verbose test foo


No other drivers / commands are hooked up aside from 'save'
in the 'test' driver.

Dan.

-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]