On Tue, Sep 09, 2014 at 12:38:04PM +0100, Richard W.M. Jones wrote: > On Tue, Sep 09, 2014 at 10:45:43AM +0200, Peter Krempa wrote: > > When a backing chain element specifies a parent in a format not known to libvirt > > we'd fail to start the VM as the chain would appear broken. > > > > To prevent this happening introduce a new disk type to collect > > unknow format specs and avoid startup failures with such disk type. > > I tested the patch series as described here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1134878#c2 > > and it sort of works. Instead of the original error, I now get > an SELinux / labelling error: > > process exited while connecting to monitor: 2014-09-09T11:31:12.591266Z qemu-system-x86_64: -drive file=/tmp/test2.img,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=writeback: could not open disk image /tmp/test2.img: Could not open backing file: Could not open '/tmp/test1.img': Permission denied > [code=1 domain=10] > > because of course the backing file is ignored rather than being > labelled: > > $ ll -Z /tmp/test[12].img > -rw-rw-r--. rjones rjones unconfined_u:object_r:user_tmp_t:s0 /tmp/test1.img > -rw-r--r--. rjones rjones unconfined_u:object_r:svirt_image_t:s0:c117,c209 /tmp/test2.img > > Now for the case that *I* care about, which is ssh and https backing > files, this doesn't matter because those are not labelled. > > Unfortunately this reveals another bug, which is that the SSH_* > variables that are required by the ssh driver are not passed through > to libvirtd. Ho hum. This is exactly why not treating unknown backing files as a fatal error is generally not helpful or desirable. When trying to rely on use of a feature that isn't supported, ocassionally you might get lucky with all the planets aligning leading the feature to work, but more often than not it is going to hit further bugs, which are even harder to diagnose. Certainly libvirt should support this new backing file format, including support for SSH, HTTP and so on, but until we do this explicitly, we should raise an immediate error as we do today rather than pretending that we expect it to work. 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