libvirt users - Jul 2016 - Blockpull behavior when interrupted

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?

Thanks,

Andrew

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 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>,
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