[libvirt-users] Blockpull behavior when interrupted

[Andrew Martin]

----- Original Message -----
> From: "Eric Blake" <eblake at redhat.com>
> To: "Andrew Martin" <amartin at xes-inc.com>
> Cc: libvirt-users at 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!