libvirt users - Jul 2016 - Re: Blockpull behavior when interrupted

----- Original Message -----
> From: "Eric Blake" <eblake@redhat.com>
> To: "Andrew Martin" <amartin@xes-inc.com>,
libvirt-users@redhat.com
> Sent: Thursday, July 21, 2016 5:40:07 PM
> Subject: Re: [libvirt-users] Blockpull behavior when interrupted
> 
> On 07/21/2016 03:05 PM, Andrew Martin wrote:
> > Hello,
> > 
> > I use snapshot-create-as followed by blockpull when creating external
> > snapshots
> > of VMs. This works well, however I am curious about the behavior of
> > blockpull
> > after an unexpected shutdown (or SIGKILL). If a blockpull is in
progress
> > and an
> > unexpected power loss occurs, will the VM continue to reference the
backing
> > file
> > for the parts of it that have not yet been copied? Or, will will the
disk
> > image
> > no longer be usable?
> 
> Blockpull is non-destructive. If it is aborted early, you can reissue a
> blockpull command and it will safely resume the task of pulling data.
> The guest-visible data remains unchanged, regardless of how much or how
> little of the blockpull has completed.  Of course, you cannot discard
> the backing file until the blockpull has completed.
> 
> An aborted block commit, on the other hand, can cause individual backing
> files to no longer represent a state that was ever seen by the guest,
> but again can be restarted to be fully completed; and the guest-visible
> data from the active layer is never corrupted even if individual backing
> files within the chain are (temporarily) out of sync with reality.
> 
> For more ideas on how to visualize things, check out my presentation at
> last year's KVM Forum:
>
http://www.linux-kvm.org/images/5/5f/03x02-Eric_Blake-Backing_Chain_Management_in_QEMU_and_libvirt.pdf
> 
Eric,

Thanks, that was a helpful overview. To clarify, block commit is changing
the backing files,but even though it is doing that, the data is consistent
even if it is interrupted?

Reviewing the presentation brought up another question. I have been thinking
about installing qemu-guest-agent so I can use --quiese with snapshot-create-as,
however I have a couple of questions:
* does the guest agent always report back to libvirt on the host if it succeeds,
fails, or has an error when attempting to sync(2)?
* isn't it a security risk to allow the guest the ability to communicate to
the
host via the guest agent port?

Also, any thoughts on utilizing ZFS snapshots in lieu of internal or external
qcow2 snapshots, at least for backup purposes? Utilizing zfs send/zfs receive
would be nice for performance when sending full image backups to a remote
server.

Thanks,

Andrew

On 07/22/2016 11:30 AM, Andrew Martin wrote:
> 
> Thanks, that was a helpful overview. To clarify, block commit is changing
> the backing files,but even though it is doing that, the data is consistent
> even if it is interrupted?
Yes, the guest's view of the data is consistent.  Intermediate backing
files may have contents that don't correspond to any historical state
seen by the guest, but the guest view is never compromised.
> 
> Reviewing the presentation brought up another question. I have been
thinking
> about installing qemu-guest-agent so I can use --quiese with
snapshot-create-as,
> however I have a couple of questions:
> * does the guest agent always report back to libvirt on the host if it
succeeds,
> fails, or has an error when attempting to sync(2)?
Guest agents only work if you can trust the guest (a malicious guest
could just lie), but in general, for a trusted guest, yes, the agent
will inform the host if there was an error quiescing data, at which
point libvirt will mark the overall command as failed.
> * isn't it a security risk to allow the guest the ability to
communicate to the
> host via the guest agent port?
It's always a security risk to trust a random guest to do anything, if
you don't trust the guest to begin with.  --quiesce, and the guest agent
in general, is only useful for trusted guests.
> 
> Also, any thoughts on utilizing ZFS snapshots in lieu of internal or
external
> qcow2 snapshots, at least for backup purposes? Utilizing zfs send/zfs
receive
> would be nice for performance when sending full image backups to a remote
server.
Patches are welcome, although ZFS may be tricky because of licensing
questions (I'm not a lawyer, but I know enough to not touch ZFS as long
as its current license doesn't play nicely with the Linux kernel)


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

----- Original Message -----
> From: "Eric Blake" <eblake@redhat.com>
> To: "Andrew Martin" <amartin@xes-inc.com>
> Cc: libvirt-users@redhat.com
> Sent: Friday, July 22, 2016 10:40:54 PM
> Subject: Re: [libvirt-users] Blockpull behavior when interrupted
> 
> On 07/22/2016 11:30 AM, Andrew Martin wrote:
> 
> > 
> > Thanks, that was a helpful overview. To clarify, block commit is
changing
> > the backing files,but even though it is doing that, the data is
consistent
> > even if it is interrupted?
> 
> Yes, the guest's view of the data is consistent.  Intermediate backing
> files may have contents that don't correspond to any historical state
> seen by the guest, but the guest view is never compromised.
> 
> > 
> > Reviewing the presentation brought up another question. I have been
> > thinking
> > about installing qemu-guest-agent so I can use --quiese with
> > snapshot-create-as,
> > however I have a couple of questions:
> > * does the guest agent always report back to libvirt on the host if it
> > succeeds,
> > fails, or has an error when attempting to sync(2)?
> 
> Guest agents only work if you can trust the guest (a malicious guest
> could just lie), but in general, for a trusted guest, yes, the agent
> will inform the host if there was an error quiescing data, at which
> point libvirt will mark the overall command as failed.
> 
> > * isn't it a security risk to allow the guest the ability to
communicate to
> > the
> > host via the guest agent port?
> 
> It's always a security risk to trust a random guest to do anything, if
> you don't trust the guest to begin with.  --quiesce, and the guest
agent
> in general, is only useful for trusted guests.
> 
> > 
> > Also, any thoughts on utilizing ZFS snapshots in lieu of internal or
> > external
> > qcow2 snapshots, at least for backup purposes? Utilizing zfs send/zfs
> > receive
> > would be nice for performance when sending full image backups to a
remote
> > server.
> 
> Patches are welcome, although ZFS may be tricky because of licensing
> questions (I'm not a lawyer, but I know enough to not touch ZFS as long
> as its current license doesn't play nicely with the Linux kernel)
Thanks for the clarification on these points!

----- Original Message -----
> From: "Eric Blake" <eblake@redhat.com>
> To: "Andrew Martin" <amartin@xes-inc.com>
> Cc: libvirt-users@redhat.com
> Sent: Friday, July 22, 2016 10:40:54 PM
> Subject: Re: [libvirt-users] Blockpull behavior when interrupted
> 
> On 07/22/2016 11:30 AM, Andrew Martin wrote:
> 
> > 
> > Thanks, that was a helpful overview. To clarify, block commit is
changing
> > the backing files,but even though it is doing that, the data is
consistent
> > even if it is interrupted?
> 
> Yes, the guest's view of the data is consistent.  Intermediate backing
> files may have contents that don't correspond to any historical state
> seen by the guest, but the guest view is never compromised.
> 
> > 
> > Reviewing the presentation brought up another question. I have been
> > thinking
> > about installing qemu-guest-agent so I can use --quiese with
> > snapshot-create-as,
> > however I have a couple of questions:
> > * does the guest agent always report back to libvirt on the host if it
> > succeeds,
> > fails, or has an error when attempting to sync(2)?
> 
> Guest agents only work if you can trust the guest (a malicious guest
> could just lie), but in general, for a trusted guest, yes, the agent
> will inform the host if there was an error quiescing data, at which
> point libvirt will mark the overall command as failed.
> 
> > * isn't it a security risk to allow the guest the ability to
communicate to
> > the
> > host via the guest agent port?
> 
> It's always a security risk to trust a random guest to do anything, if
> you don't trust the guest to begin with.  --quiesce, and the guest
agent
> in general, is only useful for trusted guests.
> 
> > 
> > Also, any thoughts on utilizing ZFS snapshots in lieu of internal or
> > external
> > qcow2 snapshots, at least for backup purposes? Utilizing zfs send/zfs
> > receive
> > would be nice for performance when sending full image backups to a
remote
> > server.
> 
> Patches are welcome, although ZFS may be tricky because of licensing
> questions (I'm not a lawyer, but I know enough to not touch ZFS as long
> as its current license doesn't play nicely with the Linux kernel)
Thanks for the clarification on these points!