libvirt users - Jan 2015 - How do you force a VM reboot (when its KPd etc) without interrupting a blockcopy?

My question is this:

If you have an ongoing blockcopy (drive-mirror) of a running transient VM, and
the VM kernel panics, can you restart the VM without interrupting the ongoing
blockcopy?

A virsh reboot won't work since if the VM is kernel panicked, its not going
to respond to ACPI requests.

On Fri, Jan 16, 2015 at 12:21:36PM -0500, Scott Sullivan
wrote:
> My question is this:
> 
> If you have an ongoing blockcopy (drive-mirror) of a running transient VM,
and the VM kernel panics, can you restart the VM without interrupting the
ongoing blockcopy?
> 
> A virsh reboot won't work since if the VM is kernel panicked, its not
going to respond to ACPI requests.
You want 'virsh reset' which does a hard reset of the CPUs / base board
and so does not require guest OS co-operation.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

On 01/16/2015 10:21 AM, Scott Sullivan wrote:
> My question is this:
> 
> If you have an ongoing blockcopy (drive-mirror) of a running transient VM,
and the VM kernel panics, can you restart the VM without interrupting the
ongoing blockcopy?
Sadly, this is not yet possible.  There is work being done in upstream
qemu to add persistent bitmap support, and the libvirt would have to be
taught to drive it.  The idea is that a persistent bitmap would allow
you to resume a copy operation from where it left off, rather than
having to start from scratch.  But as that is not implemented yet, the
best you can do is restart the copy from scratch.

You can minimize the penalty of a copy, though, by being careful about
what is being copied.  If you take an external snapshot prior to
starting a blockcopy, then you have a setup where the backing file is
large and stable, while the delta qcow2 wrapper is still relatively
small.  Copy the backing file via external means, if you have something
more efficient such as a storage pool cloner.  Meanwhile, use a shallow
blockcopy of just the qcow2 wrapper.  If that has to be restarted, it is
a much smaller file to redo; also, because it is smaller, a shallow
blockcopy is likely to finish faster.  Then, once everything is copied
to the new location, use active blockcommit to merge the temporary
wrapper back into the normal backing file.

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

On 01/16/2015 12:32 PM, Eric Blake wrote:
> On 01/16/2015 10:21 AM, Scott Sullivan wrote:
>> My question is this:
>>
>> If you have an ongoing blockcopy (drive-mirror) of a running transient
VM, and the VM kernel panics, can you restart the VM without interrupting the
ongoing blockcopy?
> Sadly, this is not yet possible.  There is work being done in upstream
> qemu to add persistent bitmap support, and the libvirt would have to be
> taught to drive it.  The idea is that a persistent bitmap would allow
> you to resume a copy operation from where it left off, rather than
> having to start from scratch.  But as that is not implemented yet, the
> best you can do is restart the copy from scratch.
>
> You can minimize the penalty of a copy, though, by being careful about
> what is being copied.  If you take an external snapshot prior to
> starting a blockcopy, then you have a setup where the backing file is
> large and stable, while the delta qcow2 wrapper is still relatively
> small.  Copy the backing file via external means, if you have something
> more efficient such as a storage pool cloner.  Meanwhile, use a shallow
> blockcopy of just the qcow2 wrapper.  If that has to be restarted, it is
> a much smaller file to redo; also, because it is smaller, a shallow
> blockcopy is likely to finish faster.  Then, once everything is copied
> to the new location, use active blockcommit to merge the temporary
> wrapper back into the normal backing file.
>
Thanks for the help Eric and Daniel. Here's what i'm seeing:

[root@test-parent-kvm-2 ~]# virsh blockjob --info f20-SPICE vda
Block Copy: [  5 %]

[root@test-parent-kvm-2 ~]# virsh reset f20-SPICE
Domain f20-SPICE was reset

[root@test-parent-kvm-2 ~]# virsh blockjob --info f20-SPICE vda
Block Copy: [  5 %]

[root@test-parent-kvm-2 ~]#

So as you see, it appears doing a virsh reset is not restarting the block copy
progress (which would be good). I just wanted a way to force a VM to reboot if
its KPd or something during a blockcopy. It appears that is exactly what virsh
reset is doing, and it also appears to not be restarting the block copy progress
(based on the paste above).

This is good news, thanks to both of you Eric and Daniel , its appreciated. Also
, do feel free to correct me if im mistaken with the above assessment.