On Fri, Jul 22, 2011 at 12:11 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf <kwolf@xxxxxxxxxx> wrote: >> Am 21.07.2011 17:01, schrieb Stefan Hajnoczi: >>> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake <eblake@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list