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

On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf <kwolf(a)redhat.com&gt; wrote: > Am 21.07.2011 17:01, schrieb Stefan Hajnoczi: >> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake <eblake(a)redhat.com&gt; 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.