[libvirt-users] 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_Manageme... -- 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_Manageme...
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!
participants (2)
-
Andrew Martin -
Eric Blake