Re: external snapshots bug

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

 



On Tue, Sep 12, 2017 at 20:49:12 +0300, Khasan Khafizov wrote:
> Suppose we have a disk with several external snapshots of it. This disk is
> attached to some domain. I found that after destroying and starting the
> domain the xml of attached disk doesn't contain all backingStore that it
> has to.
> 
> Before the restart the part of domain xml that relates to attached disk
> looks like this:
> 
>     <disk type='file' device='disk'>
> >       <driver name='qemu' type='qcow2'/>
> >       <source file='...'/>
> >       <backingStore type='file' index='1'>
> >         <format type='qcow2'/>               <!-- here is qcow2 -->
> >         <source file='...'/>
> >         <backingStore type='file' index='2'>
> >           <format type='qcow2'/>
> >           <source file='...'/>
> >           <backingStore type='file' index='3'>
> >             <format type='qcow2'/>
> >             <source file='...'/>
> >             <backingStore/>
> >           </backingStore>
> >         </backingStore>
> >       </backingStore>
> >     </disk>
> 
> 
> And after the restart like this:
> 
>     <disk type='file' device='disk'>
> >       <driver name='qemu' type='qcow2'/>
> >       <source file='...'/>
> >       <backingStore type='file' index='1'>
> >         <format type='raw'/>               <!-- here is raw -->
> >         <source file='...'/>
> >         <backingStore/>
> >       </backingStore>
> >     </disk>

Did you create the snapshot by specifying --reuse-external and providing
a pre-created qcow2 image?

> 
> So, the difference in two xml not only in depth of backing stores but in
> format type also.
> The result of it is that you can't run blockcommit that will commit overlay
> into base image if they don't have direct relations (if for example overlay
> is child of child of base image). Virsh says it can't find base in chain (
> exception
> <https://github.com/libvirt/libvirt/blob/cdecfbed027ab242467580a897a636be82d5d411/src/util/virstoragefile.c#L1667>
> ).
> Then I got that libvirt stops calling virStorageFileGetMetadataRecurse
> <https://github.com/libvirt/libvirt/blob/ed8661a309c96e4a1573dc0ca2c76ea7ff19469a/src/storage/storage_source.c#L394>
> function
> after first call because it thinks that format of first backingStore of
> disk is raw instead of qcow2. I solved it  by adding to the  qemu config
> the following line:
> 
> >  allow_disk_format_probing = 1

This is insecure.

> 
>  But in qemu config it was marked as secure hole.

Yep.

> Idea of fix is that we can try assume that backing store of qcow is qcow
> insted of raw, but I really don't know what to do to implement this idea if
> it at all possible

If you are pre-creating the images you have to specify -o
backing_fmt=qcow2 when creating them. Otherwise libvirt will treat it as
raw since probing is not allowed.

Attachment: signature.asc
Description: PGP signature

--
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]
  Powered by Linux