QEMU emits this signal when autofinalize is disabled and QEMU is waiting
for the caller to start the finalization manually.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
---
 src/qemu/qemu_backup.c   |  1 +
 src/qemu/qemu_blockjob.c | 20 +++++++++++++++++++-
 src/qemu/qemu_blockjob.h |  1 +
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_backup.c b/src/qemu/qemu_backup.c
index c7721812a5..6a5aacd9f6 100644
--- a/src/qemu/qemu_backup.c
+++ b/src/qemu/qemu_backup.c
@@ -1035,6 +1035,7 @@ qemuBackupNotifyBlockjobEnd(virDomainObj *vm,
             case QEMU_BLOCKJOB_STATE_NEW:
             case QEMU_BLOCKJOB_STATE_RUNNING:
             case QEMU_BLOCKJOB_STATE_ABORTING:
+            case QEMU_BLOCKJOB_STATE_PENDING:
             case QEMU_BLOCKJOB_STATE_PIVOTING:
             case QEMU_BLOCKJOB_STATE_LAST:
             default:
diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c
index a7aa7b3940..71dddc256c 100644
--- a/src/qemu/qemu_blockjob.c
+++ b/src/qemu/qemu_blockjob.c
@@ -55,6 +55,7 @@ VIR_ENUM_IMPL(qemuBlockjobState,
               "running",
               "concluded",
               "aborting",
+              "pending",
               "pivoting");
 
 VIR_ENUM_IMPL(qemuBlockjob,
@@ -531,6 +532,8 @@ qemuBlockJobRefreshJobs(virDomainObj *vm)
                 if (job->state == QEMU_BLOCKJOB_STATE_NEW ||
                     job->state == QEMU_BLOCKJOB_STATE_RUNNING)
                     job->newstate = newstate;
+            } else if (newstate == QEMU_BLOCKJOB_STATE_PENDING) {
+                job->newstate = newstate;
             }
             /* don't update the job otherwise */
         }
@@ -1563,6 +1566,18 @@ qemuBlockJobEventProcess(virQEMUDriver *driver,
         job->newstate = -1;
         break;
 
+    case QEMU_BLOCKJOB_STATE_PENDING:
+        /* similarly as for 'ready' state we should handle it only when
+         * previous state was 'new' or 'running' as when aborting job it can
+         * reset the internally set job state */
+        if (job->state == QEMU_BLOCKJOB_STATE_NEW ||
+            job->state == QEMU_BLOCKJOB_STATE_RUNNING) {
+            job->state = job->newstate;
+            qemuDomainSaveStatus(vm);
+        }
+        job->newstate = -1;
+        break;
+
     case QEMU_BLOCKJOB_STATE_NEW:
     case QEMU_BLOCKJOB_STATE_RUNNING:
     case QEMU_BLOCKJOB_STATE_LAST:
@@ -1684,13 +1699,16 @@ qemuBlockjobConvertMonitorStatus(int monitorstatus)
         ret = QEMU_BLOCKJOB_STATE_CONCLUDED;
         break;
 
+    case QEMU_MONITOR_JOB_STATUS_PENDING:
+        ret = QEMU_BLOCKJOB_STATE_PENDING;
+        break;
+
     case QEMU_MONITOR_JOB_STATUS_UNKNOWN:
     case QEMU_MONITOR_JOB_STATUS_CREATED:
     case QEMU_MONITOR_JOB_STATUS_RUNNING:
     case QEMU_MONITOR_JOB_STATUS_PAUSED:
     case QEMU_MONITOR_JOB_STATUS_STANDBY:
     case QEMU_MONITOR_JOB_STATUS_WAITING:
-    case QEMU_MONITOR_JOB_STATUS_PENDING:
     case QEMU_MONITOR_JOB_STATUS_ABORTING:
     case QEMU_MONITOR_JOB_STATUS_UNDEFINED:
     case QEMU_MONITOR_JOB_STATUS_NULL:
diff --git a/src/qemu/qemu_blockjob.h b/src/qemu/qemu_blockjob.h
index 741d8df6c5..e9b283da20 100644
--- a/src/qemu/qemu_blockjob.h
+++ b/src/qemu/qemu_blockjob.h
@@ -41,6 +41,7 @@ typedef enum {
     QEMU_BLOCKJOB_STATE_CONCLUDED, /* job has finished, but it's unknown
                                       whether it has failed or not */
     QEMU_BLOCKJOB_STATE_ABORTING,
+    QEMU_BLOCKJOB_STATE_PENDING,
     QEMU_BLOCKJOB_STATE_PIVOTING,
     QEMU_BLOCKJOB_STATE_LAST
 } qemuBlockjobState;
-- 
2.38.1

On Thu, Dec 08, 2022 at 14:30:47 +0100, Pavel Hrdina wrote:
> QEMU emits this signal when autofinalize is disabled and QEMU is waiting
> for the caller to start the finalization manually.

Note that this is not true. The block job transitions through the
pending state also when started with auto-finalization requested.


> 
> Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
> ---
>  src/qemu/qemu_backup.c   |  1 +
>  src/qemu/qemu_blockjob.c | 20 +++++++++++++++++++-
>  src/qemu/qemu_blockjob.h |  1 +
>  3 files changed, 21 insertions(+), 1 deletion(-)

[...]

> @@ -1563,6 +1566,18 @@ qemuBlockJobEventProcess(virQEMUDriver *driver,
>          job->newstate = -1;
>          break;
>  
> +    case QEMU_BLOCKJOB_STATE_PENDING:
> +        /* similarly as for 'ready' state we should handle it only when
> +         * previous state was 'new' or 'running' as when aborting job it can
> +         * reset the internally set job state */

Well this assumption will not work for active layer block commit, which
also transitions through the _READY state. Since you are modifying block
commit that might be relevant.

Let's see how it will be used.

If it isn't to be used with active layer block commit you should most
likely mention that in the comment for the block commit code or disallow
it altogether to prevent surprises for others wanting to use it in the
future.

> +        if (job->state == QEMU_BLOCKJOB_STATE_NEW ||
> +            job->state == QEMU_BLOCKJOB_STATE_RUNNING) {
> +            job->state = job->newstate;
> +            qemuDomainSaveStatus(vm);
> +        }
> +        job->newstate = -1;