On Tue, Mar 20, 2012 at 15:29:37 -0600, Eric Blake wrote: > The oVirt developers have stated that the real reasons they want > to have qemu reuse existing volumes when creating a snapshot are: > 1. the management framework is set up so that creation has to be > done from a central node for proper resource tracking, and having > libvirt and/or qemu create things violates the framework, and > 2. qemu defaults to creating snapshots with an absolute path to > the backing file, but oVirt wants to manage a backing chain that > uses just relative names, to allow for easier migration of a chain > across storage locations. > > When 0.9.10 added VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT (commit > 4e9953a4), it only addressed point 1, but libvirt was still using > O_TRUNC which violates point 2. Meanwhile, the new qemu > 'transaction' monitor command includes a new optional mode argument > that will force qemu to reuse the metadata of the file it just > opened (with the burden on the caller to have valid metadata there > in the first place). So, this tweaks the meaning of the flag to > cover both points as intended for use by oVirt. It is not strictly > backward-compatible to 0.9.10 behavior, but it can be argued that > the O_TRUNC of 0.9.10 was a bug. I would agree. It makes more sense if REUSE reuses the whole file including its content instead of reusing just the file name and some metadata. > Note that this flag is all-or-nothing, and only selects between > 'existing' and the default 'absolute-paths'. A more flexible > approach that would allow per-disk selections, as well as adding > support for the 'no-backing-file' mode, would be possible by > extending the <domainsnapshot> xml to have a per-disk mode, but > until we have a management application expressing a need for that > additional complexity, it is not worth doing. Every opportunity to not increase the complexity of snapshot API even moreis always welcome :-) The patch looks like it's doing what you say it's doing, so ACK (with the additional patch you plan to squash in). Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list