On Thu, Jul 25, 2019 at 01:52:01PM +0200, Pavel Hrdina wrote:
> On Wed, Jul 24, 2019 at 03:43:14PM +0100, Daniel P. Berrangé wrote:
>
> [...]
>
> > > +typedef struct _virDomainJob virDomainJob;
> > > +typedef virDomainJob *virDomainJobPtr;
> > > +struct _virDomainJob {
> > > +char *name;
> >
On Wed, Jul 24, 2019 at 03:43:14PM +0100, Daniel P. Berrangé wrote:
[...]
> > +typedef struct _virDomainJob virDomainJob;
> > +typedef virDomainJob *virDomainJobPtr;
> > +struct _virDomainJob {
> > +char *name;
> > +virDomainJobType type;
> > +virDomainJobState state;
> > +
> > +
On Wed, Jul 10, 2019 at 02:27:21PM +0200, Peter Krempa wrote:
> Currently we don't have a consolidated approach for managing
> asynchronous long-running domain jobs. Historically there were
> long-running jobs which interlocked with each other and thus there was
> only one such job possible at
On Wed, Jul 10, 2019 at 08:38:20 -0500, Eric Blake wrote:
> On 7/10/19 7:27 AM, Peter Krempa wrote:
> > Currently we don't have a consolidated approach for managing
> > asynchronous long-running domain jobs. Historically there were
> > long-running jobs which interlocked with each other and thus
On 7/10/19 7:27 AM, Peter Krempa wrote:
> Currently we don't have a consolidated approach for managing
> asynchronous long-running domain jobs. Historically there were
> long-running jobs which interlocked with each other and thus there was
> only one such job possible at given time (migration,
Currently we don't have a consolidated approach for managing
asynchronous long-running domain jobs. Historically there were
long-running jobs which interlocked with each other and thus there was
only one such job possible at given time (migration, save, restore, dump)
These jobs have a not very
