[libvirt-users] 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.
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Scott Sullivan