On Thu, Feb 06, 2014 at 12:02:11PM +0530, Kashyap Chamarthy wrote:
On Wed, Feb 05, 2014 at 10:54:15PM +0100, Gergely Horváth wrote:
Thank you Eric,
On 2014-02-05 17:23, Eric Blake wrote:
Yes, live storage migration is possible; although at the moment, qemu is lacking a way to restart the operation if it fails midstream, so libvirt only allows the operation if you are willing to temporarily make your guest transient.
What does this mean? Will I loose anything if - for example - there is not enough space on the target device?
As I understand it, no, you'll not lose anything.
Here's some old notes for live backup with 'virsh blockcopy', this was after discussing with Eric
http://kashyapc.fedorapeople.org/virt/lc-2012/live-backup-with-blockcopy.txt
Currently due to QEMU's limitation, libvirt expects a domain to be trasient. Because, blockcopy jobs last forever until canceled, which implies that they should last across domain restarts if the domain were persistent. But qemu doesn't yet provide a way to restart a copy job on domain restart. So the trick is to temporarily make the domain transient
Or it will still use the original disk image?
AFAIK, a transient guest only means it will disappear after the virtualisation session ends.
The disk image stays intact, just it'll disappear from libvirt's view, hence you take a copy of your XML file below ('virsh dumpxml') does that
virsh dumpxml $dom > file virsh undefine $dom virsh blockcopy $dom /ssd/image.raw /hdd/image.raw \ --wait --verbose --pivot virsh define file
I could not find anything about "pivot" or "pivoting"? What does --pivot do in this case?
When you "pivot", libvirt will use the new copy (i.e. /hdd/image.raw in this case), and this is done while the guest is running.
Eric, please correct if I said something wrong.
Ah, Eric already explained it more eloquently (I hit send before seeing his email). -- /kashyap