qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] BlockDeviceInfo's backing_file and ImageInfo's backing-file


From: Alberto Garcia
Subject: [Qemu-block] BlockDeviceInfo's backing_file and ImageInfo's backing-filename
Date: Fri, 6 Nov 2015 13:53:48 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]