On Fri, Aug 10, 2018 at 18:26:57 +0200, Kevin Wolf wrote: > The block-commit QMP command required specifying the top and base nodes > of the commit jobs using the file name of that node. While this works > in simple cases (local files with absolute paths), the file names > generated for more complicated setups can be hard to predict. > > This adds two new options top-node and base-node to the command, which > allow specifying node names instead. They are mutually exclusive with > the old options. > > Signed-off-by: Kevin Wolf > --- > qapi/block-core.json | 24 ++++++++++++++++++------ > blockdev.c | 32 ++++++++++++++++++++++++++++++-- > 2 files changed, 48 insertions(+), 8 deletions(-) While the below is not strictly relevant to this patch usage block-commit is not possible when using -blockdev. Thus the new arguments are not very useful otherwise. With the new options I'm getting: {"execute":"block-commit", "arguments": { "device":"libvirt-3-format", "job-id":"libvirt-3-format", "top-node":"libvirt-8-format", "base-node":"libvirt-9-format", "auto-finalize":true, "auto-dismiss":false}, "id":"libvirt-16"} {"id":"libvirt-16", "error":{"class":"GenericError", "desc":"Block node is read-only"}} I'm pointing into the backing chain so the files are declared as read-only. It works just-fine if I open them as read-write with -blockdev/blockdev-add but that obviously is not correct as you can't then share parts of the backing chain with other VMs due to image locking. libvirt-3-format is read-write and all other node names are readonly in the above example. The same also happens when using filenames: {"execute":"block-commit", "arguments" : {"device":"libvirt-3-format", "job-id":"libvirt-3-format", "top":"/var/lib/libvirt/images/rhel7.3.1483615252", "base":"/var/lib/libvirt/images/rhel7.3.1483605924", "auto-finalize":true, "auto-dismiss":false}, "id":"libvirt-13"} {"id":"libvirt-13","error":{"class":"GenericError","desc":"Block node is read-only"}} When I use the drive alias rather than the node-name for the 'device' argument it works as expected. {"execute":"block-commit", "arguments": { "device":"drive-virtio-disk0", "job-id":"drive-virtio-disk0", "top":"/var/lib/libvirt/images/rhel7.3.1483536402", "base":"/var/lib/libvirt/images/rhel7.3.1483545313"}, "id":"libvirt-18"} I was not able to find anything which would allow to reopen the file R/W in case of the block-commit operation, but I suspect it should be done automatically as previously it was done that way prior to -blockdev. Peter