[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-block] BlockDeviceInfo's backing_file and ImageInfo's backing-filename,
Alberto Garcia <=