On Mon, Oct 07, 2019 at 05:49:14PM -0400, Cole Robinson wrote:
This series is the first steps to teaching libvirt about qcow2 data_file support, aka external data files or qcow2 external metadata. A bit about the feature: it was added in qemu 4.0. It essentially creates a two part image file: a qcow2 layer that just tracks the image metadata, and a separate data file which is stores the VM disk contents. AFAICT the driving use case is to keep a fully coherent raw disk image on disk, and only use qcow2 as an intermediate metadata layer when necessary, for things like incremental backup support. The original qemu patch posting is here: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg07496.html For testing, you can create a new qcow2+raw data_file image from an existing image, like: qemu-img convert -O qcow2 \ -o data_file=NEW.raw,data_file_raw=yes EXISTING.raw NEW.qcow2 The goal of this series is to teach libvirt enough about this case so that we can correctly relabel the data_file on VM startup/shutdown. The main functional changes are * Teach storagefile how to parse out data_file from the qcow2 header * Store the raw string as virStorageSource->externalDataStoreRaw * Track that as its out virStorageSource in externalDataStore * dac/selinux relabel externalDataStore as neededFrom libvirt's perspective, externalDataStore is conceptually prettyclose to a backingStore, but the main difference is its read/write permissions should match its parent image, rather than being readonly like backingStore. This series has only been tested on top of the -blockdev enablement series, but I don't think it actually interacts with that work at the moment. Future work: * Exposing this in the runtime XML. We need to figure out an XML
This also belongs in the persistent XML.
schema. It will reuse virStorageSource obviously, but the main
thing to figure out is probably 1) what the top element name
should be ('dataFile' maybe?), 2) where it sits in the XML
hierarchy (under <disk> or under <source> I guess)
<metadataStore> maybe?
* Exposing this on the qemu -blockdev command line. Similar to how in the blockdev world we are explicitly putting the disk backing chain on the command line, we can do that for data_file too.
Historically, not being explicit on the command line and letting QEMU do the right thing has bitten us, so yes, we have to do it for data_file too.
Then like persistent <backingStore> XML the user will have the power to overwrite the data_file location for an individual VM run.
If the point of the thin qcow2 layer is to contain the dirty bitmaps for incremental backup then running this then you might as well use a different metadata_file? Otherwise the metadata won't match the actual data. OTOH, I can imagine throwing away the metadata file and starting over.
* Figure out how we expect ovirt/rhev to be using this at runtime. Possibly taking a running VM using a raw image, doing blockdev-* magic to pivot it to qcow2+raw data_file, so it can initiate incremental backup on top of a previously raw only VM? Known issues: * In the qemu driver, the qcow2 image metadata is only parsed in -blockdev world if no <backingStore> is specified in the persistent XML. So basically if there's a <backingStore> listed, we never parse the qcow2 header and detect the presence of data_file. Fixable I'm sure but I didn't look into it much yet.
This will be fixed by introducing an XML element for it. Jano
Most of this is cleanups and refactorings to simplify the actual functional changes.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
