On 07/15/2014 07:25 AM, Peter Krempa wrote:
When the backing store of a volume wasn't accessible while updating the volume definition the call would fail alltogether. In cases where we
s/alltogether/altogether/
currently (incorrectly) treat remote backing stores as local one this might lead to strange errors.
Ignore the opening errors until we figure out how to track proper volume metadata. --- src/storage/storage_backend.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index f5bfdee..fdcaada 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -1465,7 +1465,8 @@ virStorageBackendUpdateVolInfo(virStorageVolDefPtr vol, (ret = virStorageBackendUpdateVolTargetInfo(vol->target.backingStore, updateCapacity, withBlockVolFormat, - VIR_STORAGE_VOL_OPEN_DEFAULT)) < 0) + VIR_STORAGE_VOL_OPEN_DEFAULT | + VIR_STORAGE_VOL_OPEN_NOERROR) < 0)) return ret;
Works for me as a stopgap. (On IRC, we were discussing that we probably want to update the storage volume XML for <backingStore> to look a bit more like domain <disk> backingstore, at least for cases where we know the backing store is not in the same pool as the source - but that's a bigger project so worth later patches). ACK. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org