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 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.