Hi all, I noticed that query-named-block-nodes (and HMP 'info block') returns odd results when the effective backing image of a BlockDriverState is different from the string that is stored on the file.
There are two fields exposed on the API that show this information: BlockDeviceInfo's backing_file and ImageInfo's backing-filename. From the description I would expect that the former refers to the actual backing file in use (bs->backing) and the latter to the string stored in the file. That's however not what happens. Let's see a few examples: qemu-img create -f qcow2 base.img 4G qemu-img create -f qcow2 -o backing_file=base.img hd0.img qemu-img create -f qcow2 -o backing_file=hd0.img hd1.img 1) { "execute": "blockdev-add", "arguments": { "options": { "driver": "qcow2", "file": { "driver": "file", "filename": "hd1.img" }, "id": "drive0" } } } The output here is normal: BlockDeviceInfo.backing_file = hd0.img BlockDeviceInfo.image.backing-filename: hd0.img 2) { "execute": "blockdev-add", "arguments": { "options": { "driver": "qcow2", "file": { "driver": "file", "filename": "hd1.img" }, "id": "drive0", "backing": { "driver": "qcow2", "file": { "driver": "file", "filename": "base.img" } } } } } Now there's no reference to hd0.img anywhere: BlockDeviceInfo.backing_file = base.img BlockDeviceInfo.image.backing-filename: base.img 3) { "execute": "blockdev-add", "arguments": { "options": { "driver": "qcow2", "file": { "driver": "file", "filename": "hd1.img" }, "id": "drive0", "backing": "" } } } Now both fields point to hd0.img, although it hasn't been opened: BlockDeviceInfo.backing_file = hd0.img BlockDeviceInfo.image.backing-filename: hd0.img I would like to fix this but first I need to know the exact semantics of both fields, and the exact meaning of bs->backing_file. On top of that the actual backing file string is also present in the format-specific structs, e.g. BDRVQcow2State.image_backing_file, but that's not directly accessible from the API (it's not in ImageInfoSpecific). Berto