On Tue, Sep 09, 2014 at 11:04:18AM +0200, Peter Krempa wrote: > 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. Not being able to start a VM because we can't parse the backing store is a desirable feature, because that means we will not have correctly configured SELinux / DAC / cgroups for the backing store, nor correctly reported auditing info for the disks. > Should we then add a flag for the vm starting API that will bypass the > check for backing chain integrity? I don't think we need that. If we don't support the new disk format then reporting errors is the right thing to do. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list