Hello Daniel, hello Eric, Ping? Am Dienstag 01 März 2011 16:48:20 schrieb Philipp Hahn:
Currently a single storage volume with a broken backing file will disable the whole storage pool. This can happen when the backing file is on some unavailable network storage or if the backing volume is deleted, while the storage volumes using it remain. Since the storage pool can not be re-activated, re-creating the missing or deleting the now useless volumes using libvirt only is not possible.
Fixing this is a little bit tricky: 1. virStorageBackendProbeTarget() only detects the missing backing file, if the backing file format is not explicitly specified. If the backing file is created using kvm-img create -f qcow2 -o backing_fmt=qcow2,backing_file=... ... no error is detected at this stage. The new return code -3 signals that the backing file could not be opened. 2. The backingStore.format must be >= 0, since values < 0 would break virStorageVolTargetDefFormat() when dumping the XML data such as <format type='...'/> Because of this the format is faked as VIR_STORAGE_FILE_RAW. 3. virStorageBackendUpdateVolTargetInfo() always opens the backing file and thus always detects a missing backing file. Since it "only" updates the capacity, allocation, owner, group, mode and SELinux label, just ignore errors at this stage, print an error message and continue. 4. Using vol-dump on a broken volume still doesn't work, but at leas vol-destroy and pool-refresh do work now.
Any news on the review front for this issue? I know the patch might not be the perfect solution, but without any comment I don't know how to proceed or which part I should improve. Sincerely Philipp Hahn -- Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/