[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] live snapshot wiki updated
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] live snapshot wiki updated |
Date: |
Fri, 22 Jul 2011 19:05:18 +0300 |
On Fri, Jul 22, 2011 at 12:11 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf <address@hidden> wrote:
>> Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
>>> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake <address@hidden> 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.
- [Qemu-devel] [libvirt] Re: live snapshot wiki updated, (continued)
- Message not available
- Message not available
- Re: [Qemu-devel] live snapshot wiki updated, Stefan Hajnoczi, 2011/07/21
- Re: [Qemu-devel] live snapshot wiki updated, Blue Swirl, 2011/07/21
- Re: [Qemu-devel] live snapshot wiki updated, Stefan Hajnoczi, 2011/07/22
- Re: [Qemu-devel] live snapshot wiki updated, Blue Swirl, 2011/07/22
- Re: [Qemu-devel] live snapshot wiki updated, Kevin Wolf, 2011/07/22
- Re: [Qemu-devel] live snapshot wiki updated, Stefan Hajnoczi, 2011/07/22
- Re: [Qemu-devel] live snapshot wiki updated,
Blue Swirl <=
- Re: [Qemu-devel] live snapshot wiki updated, Kevin Wolf, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Daniel P. Berrange, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Anthony Liguori, 2011/07/19
- Re: [Qemu-devel] live snapshot wiki updated, Jes Sorensen, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Kevin Wolf, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Jes Sorensen, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Kevin Wolf, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Blue Swirl, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Eric Blake, 2011/07/20
- Re: [Qemu-devel] live snapshot wiki updated, Blue Swirl, 2011/07/20