On Sun, Aug 11, 2024 at 17:34:45 +0300, Nikolai Barybin via Devel wrote: > There are use cases when the existing disks (i.e. LVM) are wanted > to be used with advanced features. For this purpose QEMU allows > data-file feature for qcow2 files: metadata is kept in the qcow2 > file like usual, but guest data is written to an external file. > These patches enable support for this feature in libvirt. So this feature was once attempted to be added but was never finished and the comitted bits were reverted eventually. (I've purged my local archive so I don't have the link handy but I can look if you want the links to the old posting) It was deemed that this doesn't really add any performance benefit over storing the actual qcow2 with data inside. The qcow2 with data can be stored inside the LV or other block device for that matter and thus can provide all features that are necessary. The data file feature makes also the management of the metadata and data much more complex, for a very bad trade-off. At this point with 'qemu-img measure' it's easy to query the necessary size to have a fully allocated qcow2 inside the block device. Based on the history of this I'd like to ask you to summarize justifications and reasons for adding this feature before continuing. > Nikolai Barybin (3): > conf: add data-file feature and related fields to virStorageSource > storage: add qcow2 filename parsing from header > qemu: enable qcow2 data-file attach to VM on start > > src/conf/storage_source_conf.c | 8 ++++ > src/conf/storage_source_conf.h | 5 ++ > src/qemu/qemu_block.c | 45 ++++++++++++++++++ > src/qemu/qemu_cgroup.c | 3 ++ > src/qemu/qemu_namespace.c | 6 +++ > src/storage_file/storage_file_probe.c | 66 +++++++++++++++++++++++---- > src/storage_file/storage_source.c | 38 ++++++++++++++- A quick skim through the pathces shows following bits missing: - any form of tests - XML formating and parsing of the path (needed as you need the path of the data file to be user-configurable for cases when user declares the backing chain in the XML and also to be overridable. Additionally we need to record the path for cases when libvirtd/virtqemud restarts as we must not try to re-probe the image afterwards) - security driver intergration (any of the above will not work if the data file is not accessible as it won't be chown'd/relabelled) Few more comments inline.
