Looks like the rhel-9 git repo is forward-porting the commit from rhel-8 adding the downstream feature flag allowing libvirt to use 'x-blockdev-reopen' as stable for changing the read-only/read-write mode:

https://gitlab.com/redhat/rhel/src/qemu-kvm/qemu-kvm/-/commit/acdc84c1077be7d347414f781014ea785ce41d7b

Peter,

 feels like this bug should be assigned to yourself (as both the originating bugs are)? Let me know if this is not the case.

Well, the QEMU work was done by Kevin originally and I've opened this to track that the downstream commit is still necessary (without knowing that it would actually be forward-ported automatically).

For now I can keep it assigned to myself, especially since there's nothing to do for now as the commit is already in the build.

I'll set this to POST based that the commit is already in.

Test on qemu-kvm-6.0.0-7.el9, "blockdev-reopen" not be found, but "x-blockdev-reopen" works ok, bellow is the detail.

Test Env:
  kernel:5.13.0-0.rc4.33.el9.x86_64
  qemu-kvm:qemu-kvm-6.0.0-7.el9

Test Steps:
 1.Start guest with qemu cmd:
    /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox on  \
    -machine q35,memory-backend=mem-machine_mem \
    -device pcie-root-port,id=pcie-root-port-0,multifunction=on,bus=pcie.0,addr=0x1,chassis=1 \
    -device pcie-pci-bridge,id=pcie-pci-bridge-0,addr=0x0,bus=pcie-root-port-0  \
    -nodefaults \
    -device VGA,bus=pcie.0,addr=0x2 \
    -m 30720 \
    -object memory-backend-ram,size=30720M,id=mem-machine_mem  \
    -smp 10,maxcpus=10,cores=5,threads=1,dies=1,sockets=2  \
    -cpu 'Cascadelake-Server-noTSX',+kvm_pv_unhalt \
    -chardev socket,wait=off,server=on,path=/tmp/monitor-qmpmonitor1-20210629-061603-yaFmNOE5,id=qmp_id_qmpmonitor1  \
    -mon chardev=qmp_id_qmpmonitor1,mode=control \
    -chardev socket,wait=off,server=on,path=/tmp/monitor-catch_monitor-20210629-061603-yaFmNOE5,id=qmp_id_catch_monitor  \
    -mon chardev=qmp_id_catch_monitor,mode=control \
    -device pvpanic,ioport=0x505,id=idQmYevF \
    -chardev socket,wait=off,server=on,path=/tmp/serial-serial0-20210629-061603-yaFmNOE5,id=chardev_serial0 \
    -device isa-serial,id=serial0,chardev=chardev_serial0  \
    -chardev socket,id=seabioslog_id_20210629-061603-yaFmNOE5,path=/tmp/seabios-20210629-061603-yaFmNOE5,server=on,wait=off \
    -device isa-debugcon,chardev=seabioslog_id_20210629-061603-yaFmNOE5,iobase=0x402 \
    -device pcie-root-port,id=pcie-root-port-1,port=0x1,addr=0x1.0x1,bus=pcie.0,chassis=2 \
    -device qemu-xhci,id=usb1,bus=pcie-root-port-1,addr=0x0 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
    -object iothread,id=iothread0 \
    -device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3 \
    -blockdev node-name=file_image1,driver=file,auto-read-only=on,discard=unmap,aio=native,filename=/home/kvm_autotest_root/images/rhel900-64-virtio-scsi.qcow2,cache.direct=on,cache.no-flush=off \
    -blockdev node-name=drive_image1,driver=qcow2,read-only=off,cache.direct=on,cache.no-flush=off,file=file_image1 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,write-cache=on,bus=pcie-root-port-2,addr=0x0,iothread=iothread0 \
    -device pcie-root-port,id=pcie-root-port-3,port=0x3,addr=0x1.0x3,bus=pcie.0,chassis=4 \
    -device virtio-net-pci,mac=9a:69:d8:d4:4d:f5,id=idIjkF9L,netdev=id5mRhja,bus=pcie-root-port-3,addr=0x0  \
    -netdev tap,id=id5mRhja,vhost=on  \
    -vnc :0  \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot menu=off,order=cdn,once=c,strict=off \
    -enable-kvm \
    -device pcie-root-port,id=pcie_extra_root_port_0,multifunction=on,bus=pcie.0,addr=0x3,chassis=5 \
    -monitor stdio \
    -qmp tcp:0:3000,server=on,wait=off \

 2. Add persistent bitmap to "drive_image1"
     { "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive_image1", "name": "bitmap0","persistent":true}}

 3. Create target snapshot node
     {'execute':'blockdev-create','arguments':{'options': {'driver':'file','filename':'/root/sn1','size':21474836480},'job-id':'job1'}}
     {'execute':'blockdev-add','arguments':{'driver':'file','node-name':'drive_sn1','filename':'/root/sn1'}}
     {'execute':'blockdev-create','arguments':{'options': {'driver': 'qcow2','file':'drive_sn1','size':21474836480,'backing-file':'/home/kvm_autotest_root/images/rhel900-64-virtio-scsi.qcow2','backing-fmt':'qcow2'},'job-id':'job2'}}
     {'execute':'blockdev-add','arguments':{'driver':'qcow2','node-name':'sn1','file':'drive_sn1','backing':null}}
     {'execute':'job-dismiss','arguments':{'id':'job1'}}
     {'execute':'job-dismiss','arguments':{'id':'job2'}}

 4. Do snapshot
     {"execute":"blockdev-snapshot","arguments":{"node":"drive_image1","overlay":"sn1"}}

 5. Add persistent bitmap on snapshot node
     { "execute": "block-dirty-bitmap-add", "arguments": {"node": "sn1", "name": "bitmap0","persistent":true}}

 6. Remove all bitmaps for both snapshot and base
     { "execute": "transaction", "arguments": { "actions": [ {"type": "block-dirty-bitmap-remove","data":{"node":"drive_image1","name":"bitmap0"}},{"type": "block-dirty-bitmap-remove","data":{"node":"sn1","name":"bitmap0"}}]}}
{"error": {"class": "GenericError", "desc": "Bitmap 'bitmap0' is readonly and cannot be modified"}}

 7. Reopen the backing image by "blockdev-reopen"
     {'execute':'blockdev-reopen','arguments':{'driver':'qcow2','node-name':'drive_image1', "read-only":false,'file':'file_image1'}}
{"error": {"class": "CommandNotFound", "desc": "The command blockdev-reopen has not been found"}}

 8. Reopen the backing image by "x-blockdev-reopen"
     {'execute':'x-blockdev-reopen','arguments':{'driver':'qcow2','node-name':'drive_image1', "read-only":false,'file':'file_image1'}}
{"return": {}}

 9. Remove all bitmaps for both snapshot and base
     { "execute": "transaction", "arguments": { "actions": [ {"type": "block-dirty-bitmap-remove","data":{"node":"drive_image1","name":"bitmap0"}},{"type": "block-dirty-bitmap-remove","data":{"node":"sn1","name":"bitmap0"}}]}}
{"return": {}}


 And Bug 1867087 - Forward-port 'blockdev-reopen' enablement upstream on RHEL8 is still in NEW Status.

 So, Peter
   According to step7 and step8, also bz1867087,
   Please help to check if the stable interface means "x-blockdev-reopen" or "blockdev-reopen"?

Thanks,
Aliang

(In reply to aihua liang from comment #6)

[...]

>  So, Peter
>    According to step7 and step8, also bz1867087,
>    Please help to check if the stable interface means "x-blockdev-reopen" or
> "blockdev-reopen"?

Sorry for a late response, I was on PTO.

the downstream libvirt tree we have for rhel-9 forward-ports the compatibility patches which make use of x-blockdev-reopen with the '__com.redhat_rhel-av-8_2_0-api' feature flag. Since downstream qemu also forward-ported the rhel-8 era patch it's compatible as is. Libvirt then has another bug open to adapt to the differences between blockdev-reopen and x-blockdev-reopen once the upstream work on blockdev reopen is complete.

Thus what we have here is sufficient.

According to Perter's reply in comment 9 and test result in comment 6, set bug's status to "Verified".