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

[Scott Sullivan]

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.

[Daniel P. Berrange]

Post by Scott Sullivan
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

[Eric Blake]

Post by Scott Sullivan
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.

[Scott Sullivan]

Post by Eric Blake

Post by Scott Sullivan
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:

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

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

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

[***@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.