[libvirt] [PATCH 5/5] utils: storage: Fall back to "raw" disk on backing store parse failure

Peter Krempa pkrempa at redhat.com
Tue Sep 9 09:04:18 UTC 2014


On 09/09/14 11:01, Daniel P. Berrange wrote:
> On Tue, Sep 09, 2014 at 10:45:48AM +0200, Peter Krempa wrote:
>> When libvirt can't parse the backing store format for some reasons we
>> should fall back to something safe rather than marking the backing chain
>> as broken.
> 
> I'm not really convinced that falling back to raw is the "safe" option
> vs reporting an error for the backing chain.
> 
> There are a few reasons why we probe backing files
> 
>  - To report the backing file in the storage vol XML
>  - To relabel disks to grant QEMU access (SElinux, DAC, CGroups)
>  - To support APIs like block rebase that affect backing file
> 
> I don't think that falling back to raw is going to make any of those
> scenarios "do the right thing" when they find an unknown backing
> store format. Rather things will simply fail in different, more
> obscure ways due to libvirt treating the backing file differently
> than QEMU. I think it is better than we report an explicit error
> upfront when we can't interpret backing store, as this will make it
> clear that libvirt can't work and likely mean that we find out about
> new features we need to support sooner.
> 

Well we do exactly that right now. Although this disallows to start a VM
that uses an obscure (read as: unknown to libvirt) backing path
specification which causes grief.

Should we then add a flag for the vm starting API that will bypass the
check for backing chain integrity?

Peter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140909/e29dc68f/attachment-0001.sig>


More information about the libvir-list mailing list