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

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

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?


Attachment: signature.asc
Description: OpenPGP digital signature

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