On Fri, Jul 22, 2011 at 12:11 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf <kwolf@redhat.com> wrote:
Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake <eblake@redhat.com> wrote:
Thank you for persisting - you've found another hole that needs to be plugged. It sounds like you are proposing that after a qemu process dies, that libvirt re-reads the qcow2 metadata headers, and validates that the backing file information has not changed in a manner unexpected by libvirt. If it has, then the qemu process that just died was compromised to the point that restarting a new qemu process from the old image is now a security risk. So this is _yet another_ security aspect that needs to be coded into libvirt as part of hardening sVirt.
The backing file information changes when image streaming completes.
Before: fedora.img <- my_vm.qed After: my_vm.qed (fedora.img is no longer referenced)
The image streaming operation copies data out of fedora.img and populates my_vm.qed. When image streaming completes, the backing file is no longer needed and my_vm.qed is updated to drop the backing file.
I think we need to design carefully to prevent QEMU and libvirt making incorrect assumptions about who does what. I really wish that all this image file business was outside QEMU and libvirt - that we had a separate storage management service which handled the details. QEMU would only do block device operations (no image format manipulation), and libvirt would only delegate to the storage management service.
And how do you implement that in a way that works on all platforms, and without root privileges? I can't see this happen unless it stays completely optional.
The cross-platform way would be an iSCSI target that understands image formats. But iSCSI requires copying when doing I/O and we can't pass through virtio-blk.
The guest could use iSCSI directly using the network interface without virtio-blk. This setup wouldn't give max performance in local use but it could also be useful in some networked setups and probably more useful than NBD.