Re: [libvirt-users] Blockpull behavior when interrupted
----- Original Message -----
From: "Eric Blake" <eblake(a)redhat.com>
To: "Andrew Martin" <amartin(a)xes-inc.com>, libvirt-users(a)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_Manag...
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