On Mon, Apr 21, 2014 at 03:22:43PM -0600, Eric Blake wrote:
On 04/17/2014 04:20 AM, Martin Kletzander wrote:Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1019926 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=868673 Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> --- src/libvirt_private.syms | 2 +- src/qemu/qemu_domain.c | 3 +++ src/util/virstoragefile.c | 15 +++++++++++++++ src/util/virstoragefile.h | 2 ++ 4 files changed, 21 insertions(+), 1 deletion(-)@@ -1850,7 +1851,6 @@ virStorageSourcePoolModeTypeToString; virStorageTypeFromString; virStorageTypeToString; - # util/virstring.hSpurious whitespace change.+ +bool +virStorageFormatMaySupportSnapshots(enum virStorageFileFormat format) +{ + if (format == VIR_STORAGE_FILE_AUTO || + format == VIR_STORAGE_FILE_AUTO_SAFE) + return true; + + /* Better safe than sorry */ + if (format <= VIR_STORAGE_FILE_NONE || + format >= VIR_STORAGE_FILE_LAST) + return false; + + return !!fileTypeInfo[format].getBackingStore;Hmm, how does this compare with the recent commit db7d7c0e which added the VIR_STORAGE_FILE_BACKING marker? I made that separation in order to state that all formats less than the marker do not have a getBackingStore callback (well, other than the exceptions of the _AUTO and _AUTO_SAFE formats which are less than 0), and all formats >= that marker DO have a potential for a backing store. Should this code be using that new constant instead of probing the existence of getBackingStore? Or conversely, should the domain_conf.c code that I touched in that patch instead be using this new function instead of relying on the VIR_STORAGE_FILE_BACKING marker?
TBH, I haven't noticed the change, this function just works. I first
tried to enumerate all the VIR_STORAGE_FILE_* formats, but that looked
terrible and it haven't met the goal I had.
The aim in commit db7d7c0e differs a bit, I guess. My point was that
we are opening files just to close them in a while, because we have no
getBackingStore() function (the bug is opened about /dev/sr0 without
media in the drive, which should "just work" and it doesn't).
Since all formats >= VIR_STORAGE_FILE_BACKING have .getBackingStore
specified, this function and the approach in db7d7c0e currently
differs only for VIR_STORAGE_FILE_AUTO(_SAFE), but those can't be
specified in the backing chain, right?
One more thing in which this differs is a format change in future, but
IIUC, the order of the elements in the enum can be changed, so if new
format without backing support is added or backing support is
implemented for QED, re-ordering of those elements will solve it.
Having said all that, I think changing either approach to the
different one is fine, but changing my patch to the following one will
probably be the cleanest way.
Martin
diff --git i/src/qemu/qemu_domain.c w/src/qemu/qemu_domain.c
index cdd4601..5bde917 100644
--- i/src/qemu/qemu_domain.c
+++ w/src/qemu/qemu_domain.c
@@ -2246,11 +2246,14 @@ qemuDomainCheckDiskPresence(virQEMUDriverPtr driver,
VIR_DEBUG("Checking for disk presence");
for (i = vm->def->ndisks; i > 0; i--) {
disk = vm->def->disks[i - 1];
+ enum virStorageFileFormat format = virDomainDiskGetFormat(disk);
if (!virDomainDiskGetSource(disk))
continue;
- if (qemuDomainDetermineDiskChain(driver, vm, disk, false) >= 0 &&
+ if ((format < VIR_STORAGE_FILE_NONE ||
+ format >= VIR_STORAGE_FILE_BACKING) &&
+ qemuDomainDetermineDiskChain(driver, vm, disk, false) >= 0 &&
qemuDiskChainCheckBroken(disk) >= 0)
continue;
--
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list