Bug 2226576

Summary: Libvirt should popup operation unsupported err for blockjob --abort during a copy-storage migration
Product: Red Hat Enterprise Linux 9 Reporter: Han Han <hhan>
Component: libvirtAssignee: Virtualization Maintenance <virt-maint>
libvirt sub component: Live Migration QA Contact: Virtualization Bugs <virt-bugs>
Status: CLOSED NOTABUG Docs Contact:
Severity: unspecified    
Priority: unspecified CC: fjin, pkrempa, virt-maint, yafu
Version: 9.3Flags: hhan: needinfo-
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-26 12:05:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
The daemon log for the steps above none

Description Han Han 2023-07-26 02:18:36 UTC
Created attachment 1979993 [details]
The daemon log for the steps above

Description of problem:
As subject

Version-Release number of selected component (if applicable):
libvirt-9.5.0-3.el9.x86_64
qemu-kvm-8.0.0-9.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Prepare two hosts for migration. Start a guest on one host
2. Migrate the VM with --copy-storage-all
➜  ~ virsh migrate --live rhel-9.2 qemu+ssh://root$DEST/system --copy-storage-all

3. At the same time of step2, try to cancel the migration by blockjob --abort
➜  ~ virsh blockjob rhel-9.2 vda --abort
error: Requested operation is not valid: domain is not running


Actual results:
As above

Expected results:
Although "blockjob --abort" should not cancel the migration, it should return the operation unsupported err directly.

Additional info:

Comment 1 Han Han 2023-07-26 02:24:23 UTC
BTW, the "blockjob --abort" sub-command is blocked until the migration is finished

Comment 2 Peter Krempa 2023-07-26 06:02:24 UTC
Note that this behaviour is exactly the same as any other command which would modify the state of the VM, such as unplugging a device.

The blockjob itself is considered internal for the use of the migration.

In the above description I don't see any form of justification why we should treat the blockjobs differently than anything else, could you please elaborate?