| Message ID | 1418632081-20667-12-git-send-email-den@openvz.org |
|---|---|
| State | New |
| Headers | show |
Am 15.12.2014 um 09:27 hat Denis V. Lunev geschrieben: > From: Roman Kagan <rkagan@parallels.com> > > Add backing file support to Parallels format driver. > > That said, I think backing file operations should end up in the generic > block layer, but that's a longer story... > > Signed-off-by: Roman Kagan <rkagan@parallels.com> > Signed-off-by: Denis V. Lunev <den@openvz.org> > CC: Jeff Cody <jcody@redhat.com> > CC: Kevin Wolf <kwolf@redhat.com> > CC: Stefan Hajnoczi <stefanha@redhat.com> How are users supposed to make use of this? bs->backing_file isn't set during parallels_open(), so you generally dont' get a backing file. Users might manually add -drive backing=..., but is there really no support for storing the backing file in the image format? If so, perhaps it's better not to support backing files at all here. Kevin
On Mon, Dec 15, 2014 at 01:30:03PM +0100, Kevin Wolf wrote: > Am 15.12.2014 um 09:27 hat Denis V. Lunev geschrieben: > > From: Roman Kagan <rkagan@parallels.com> > > > > Add backing file support to Parallels format driver. > > > > That said, I think backing file operations should end up in the generic > > block layer, but that's a longer story... > > > > Signed-off-by: Roman Kagan <rkagan@parallels.com> > > Signed-off-by: Denis V. Lunev <den@openvz.org> > > CC: Jeff Cody <jcody@redhat.com> > > CC: Kevin Wolf <kwolf@redhat.com> > > CC: Stefan Hajnoczi <stefanha@redhat.com> > > How are users supposed to make use of this? bs->backing_file isn't set > during parallels_open(), so you generally dont' get a backing file. > > Users might manually add -drive backing=..., but is there really no > support for storing the backing file in the image format? If so, perhaps > it's better not to support backing files at all here. Parallels virtual disks (as also used by ploop, http://openvz.org/Ploop) consist of a descriptor xml file and one or more data files. The data files may have delta/backing relationships; those relationships are only stored in the descriptor file. The original parallels driver in qemu used to support direct access to the data files. This patch makes it possible for such a data file to be a delta WRT a backing file, specified externally (see e.g. the patch to the tests). The code for parsing the descriptor xml and filling in the delta/backing relations isn't there yet; we haven't yet figured out where it fits best. Still it makes up a perfectly valid usecase to figure out those relations by some external means (e.g. eye inspection of the descriptor file :) and construct appropriate JSON filename for use in any scenario where a readonly image can be used in qemu. Roman.
diff --git a/block/parallels.c b/block/parallels.c index 2d3e962..718274b 100644 --- a/block/parallels.c +++ b/block/parallels.c @@ -419,6 +419,11 @@ static int parallels_read(BlockDriverState *bs, int64_t sector_num, if (ret < 0) { return ret; } + } else if (bs->backing_hd) { + int ret = bdrv_read(bs->backing_hd, sector_num, buf, n); + if (ret < 0) { + return ret; + } } else { memset(buf, 0, n << BDRV_SECTOR_BITS); } @@ -454,6 +459,7 @@ static BlockDriver bdrv_parallels = { .bdrv_read = parallels_co_read, .bdrv_close = parallels_close, .bdrv_co_get_block_status = parallels_co_get_block_status, + .supports_backing = true, }; static void bdrv_parallels_init(void)