Re: [BUG] in [PATCHv3 10/19] storage: remember relative names in backing chain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Eric,

On Thursday 18 October 2012 00:30:21 Eric Blake wrote:
>              if (virBackingStoreIsFile(backing)) {
>                  meta->backingStoreIsFile = true;
> +                meta->backingStoreRaw = meta->backingStore;
>                  meta->backingStore = absolutePathFromBaseFile(path,
> backing);
> -            } else { 
> -                meta->backingStore = strdup(backing);
> +                if (meta->backingStore == NULL) {
> +                    virReportOOMError();
> +                    VIR_FREE(backing);
> +                    return -1;
> +                }
>              }

this broke libvirt again when a storage pool contains storage volumes, which 
(currently) miss their backing file; see my previous commit 0ed445e7 for 
details.

      virsh vol-create-as --format qcow2 default back.qcow2 1G
      virsh vol-create-as --format qcow2 --backing-vol-format 
qcow2 --backing-vol back.qcow2 default next.qcow2 1G
      virsh vol-delete --pool default back.qcow2
      pkill libvirtd
      libvirtd -l
2012-11-07 12:43:33.279+0000: 22175: info : libvirt version: 1.0.0
2012-11-07 12:43:33.279+0000: 22175: error : absolutePathFromBaseFile:542 : 
Can't canonicalize path '/var/lib/libvirt/images/base.qcow2': No such file or 
directory
2012-11-07 12:43:33.280+0000: 22175: error : storageDriverAutostart:115 : 
Failed to autostart storage pool 'default': Can't canonicalize 
path '/var/lib/libvirt/images/base.qcow2': No such file or directory

(gdb) bt
#0  absolutePathFromBaseFile (base_file=<value optimized out>, 
path=0x7f27a0031d00 "/var/lib/libvirt/images/base.qcow2") at 
util/storage_file.c:541
#1  0x00007f27b6769bdf in virStorageFileGetMetadataFromBuf 
(path=0x7f27a0009510 "/var/lib/libvirt/images/next.qcow2", fd=<value 
optimized out>, format=<value optimized out>)
    at util/storage_file.c:728
#2  virStorageFileGetMetadataFromFD 
(path=0x7f27a0009510 "/var/lib/libvirt/images/next.qcow2", fd=<value 
optimized out>, format=<value optimized out>) at util/storage_file.c:932
#3  0x00007f27acd07c94 in virStorageBackendProbeTarget (conn=<value optimized 
out>, pool=0x7f27a0012060) at storage/storage_backend_fs.c:94
#4  virStorageBackendFileSystemRefresh (conn=<value optimized out>, 
pool=0x7f27a0012060) at storage/storage_backend_fs.c:849
#5  0x00007f27accfd560 in storagePoolStart (obj=0x1c915a0, flags=<value 
optimized out>) at storage/storage_driver.c:700


There's another bug when doing a 'virsh vol-dumpxml' on such a broken image 
file, for which I'm currently working on a patch. That patch works fine with 
my older version of libvirt, but I noticed that with 1.0.0+git I can't no 
longer start that pool containing my broken test image.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn@xxxxxxxxxxxxx
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

Attachment: signature.asc
Description: This is a digitally signed message part.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]