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(a)redhat.com>
---
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.h
Spurious 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?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org