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