Re: [libvirt] [Qemu-devel] live snapshot wiki updated

On 07/19/11 16:24, Eric Blake wrote: > [adding the libvir-list] > On 07/19/2011 08:09 AM, Jes Sorensen wrote: >> Urgh, libvirt parsing image files is really unfortunate, it really >> doesn't give me warm fuzzy feelings :( libvirt really should not know >> about internals of image formats. > > But even if you add new features to qemu to avoid needing this in the > future, it doesn't change the past - libvirt will always have to know > how to parse image files understood by older qemu, and so as long as > libvirt already knows how to do that parsing, we might as well take > advantage of it. What has been done here in the past is plain wrong. Continuing to do it isn't the right thing to do here. > Besides, I feel that having a well-documented file format, so that > independent applications can both parse the same file with the same > semantics by obeying the file format specification, is a good design goal. We all know that documentation is rarely uptodate, new features may not get added and libvirt will never be able to keep up. The driver for a file format belongs in QEMU and nowhere else. >>> It would be nice if libvirt had a way to pass fds for every disk and >>> backing file up front; then, SELinux can work around the lack of NFS >>> per-file labelling by blocking open() in qemu. In fact, this has >>> already been proposed: >> >> A cleaner solution seems to have libvirt provide a call-back allowing >> QEMU to call out and have libvirt open a file descriptor instead. This >> way libvirt can validate it and open it for QEMU and pass it back. > > Yes, that could probably be made to work with libvirt. I am a little frustrated this approach wasn't taken up front instead of the evil hack of having libvirt attempt to parse image files. >> If we cannot do something like this, I would prefer to have backing >> files on NFS should simply not be supported when running in an selinux >> setup. > > As nice as that sentiment is, it will never fly, because it would be a > regression in current behavior. The whole reason that the virt_use_nfs > SELinux bool exists is that some people are willing to make the partial > security tradeoff. Besides, the use of sVirt via SELinux is more than > just open() protection - while the current virt_use_nfs bool makes NFS > less secure than otherwise possible, it still gives some nice guarantees > to the rest of the qemu process such as passthrough accesses to local > pci devices. Well leaving things at status quo is not making it worse, it just leaves an evil in place.