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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list