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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list