On 07/15/14 22:29, Eric Blake wrote:
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.
I've fixed the problems pointed out in the individual reviews and pushed
this series.
Thanks.
Peter