On Tue, Jul 16, 2013 at 10:47:54AM +0200, Martin Kletzander wrote:
On 07/16/2013 10:40 AM, Daniel P. Berrange wrote:
On Tue, Jul 16, 2013 at 08:14:54AM +0200, Martin Kletzander wrote:
On 07/15/2013 05:31 PM, Ján Tomko wrote:
On 07/02/2013 11:35 AM, Guannan Ren wrote:
If one of backing files for disk source doesn't exist, the guest will not be able to find and use the disk even though the disk still exists in guest xml definition. So reporting an error make more sense.
Adding virFileAccessibleAs() to check if the backing file described in disk meta exist in real path. If not, report error. the uid and gid arguments don't have so much meannings for F_OK, so give 0 for them. --- src/util/virstoragefile.c | 23 +++++++++++++++-------- tests/virstoragetest.c | 16 ++++++++-------- 2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 27aa4fe..cb61e5b 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c
@@ -870,14 +877,10 @@ virStorageFileGetMetadataInternal(const char *path, !!directory, backing, &meta->directory, &meta->backingStore) < 0) { - /* the backing file is (currently) unavailable, treat this - * file as standalone: - * backingStoreRaw is kept to mark broken image chains */ - meta->backingStoreIsFile = false; - backingFormat = VIR_STORAGE_FILE_NONE; - VIR_WARN("Backing file '%s' of image '%s' is missing.", - meta->backingStoreRaw, path); - + VIR_ERROR(_("Backing file '%s' of image '%s' is missing."), + meta->backingStoreRaw, path); + VIR_FREE(backing); + goto cleanup; } } VIR_FREE(backing);
This change means you won't be able to start the pool if one of the files is missing a backing file. I've forwarded a patch [1] from/for [2] that ignores missing files on pool start and there is a bug [3] requesting that we ignore other files as well. I feel like this is going in the other direction.
Wouldn't it be enough to check for them on domain start-up and leave the pool running even if one of those volumes doesn't have an existing backing file?
How about making it configurable for the pool? There are definitely some users who want the pool to reflect actual info after pool-refresh.
I don't think this needs to be configurable. The pool should show *every* single file, regardless of whether the file has a broken backing file. We shouldn't be trying to second guess what the user wants to do with a image with broken backing file. Just expose as much info as we have and let them deal with the problem.
I was thinking about the case that was mentioned in Jan's link to bugzilla, where they wanted to keep even deleted volumes. Since I disagree with that for normal pool, we could make it configurable for such use-cases (although it looks more like invalid usage of our pools in that BZ).
Which BZ are you referring to ? I read BZ 977706 to be about not causing errors during pool-refresh if a 2nd node has deleted the volume while the first node is in the middle of refresh. This isn't about keeping deleted volumes visible. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|