[libvirt-users] Can I move the disk image of the guest while it is running?

[Andrew Martin]

----- Original Message -----
> From: "Eric Blake" <eblake at redhat.com>
> To: "Gergely Horváth" <gergely.horvath at inepex.com>, libvirt-users at redhat.com
> Sent: Wednesday, February 5, 2014 4:47:47 PM
> Subject: Re: [libvirt-users] Can I move the disk image of the guest while it is running?
> 
> On 02/05/2014 02:54 PM, 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? Or it will still use the original
> > disk image?
> 
> If blockcopy fails before mirroring is in sync, such as for insufficient
> space on the destination, then the source is still valid, with no data
> loss.  If it reaches sync, then both source and destination are copies
> of each other until you quit the operation (the --wait flag tells virsh
> to automatically wait for sync, and the --pivot flag says to quit the
> operation as soon as sync is reached, rather than doing an indefinite
> mirror).  As long as the guest doesn't quit in the meantime, you haven't
> lost anything.  If the guest powers itself off in the middle of the
> blockcopy, the blockcopy will fail, but the original is still intact at
> the state it was when the guest shut down.
> 
> > 
> > AFAIK, a transient guest only means it will disappear after the
> > virtualisation session ends.
> 
> Correct, which is why you can then re-define the guest with the XML you
> saved earlier, so that it is once again persistent and can be safely
> powered off.  If blockcopy --pivot succeeded, then the guest uses only
> the destination, and you have successfully gotten rid of the need to
> refer to the source.
> 
> > 
> >> virsh dumpxml $dom > file
> >> virsh undefine $dom
> >> virsh blockcopy $dom /ssd/image.raw /hdd/image.raw \
> >>   --wait --verbose --pivot
> >> virsh define file
> 
> Oh, I just realized a caveat - before redefining the file, you'll need
> to edit it to reflect a successful blockcopy (otherwise, if the guest
> stops and then is rebooted, the reboot will still use the original
> source, rather than the destination); a safer set of steps might be:
> 
> virsh dumpxml $dom > file
> virsh undefine $dom
> if virsh blockcopy $dom /ssd/image.raw /hdd/image.raw \
>    --wait --verbose --pivot; then
>   virsh dumpxml $dom > file # refresh the xml to reflect new disk source
> fi
> virsh define file
> 
> so that file restores you to the original disk location if blockcopy
> fails, but tracks the new location if blockcopy succeeds.
> 
> [In my development work, I've been testing on throwaway disks, where I
> don't care if I clobber things by starting over again - but in a
> production environment, it pays to be more careful, and possibly to
> experiment on a safe domain with throwaway disk before doing it on your
> real domain]
> 
> > 
> > I could not find anything about "pivot" or "pivoting"? What does --pivot
> > do in this case?
> 
> --pivot says to break mirroring by using just the destination (in other
> words, pivot away from the source).  The alternative is to use --finish,
> which says break mirroring by using just the source (in other words, the
> destination is now a point-in-time snapshot at the time you broke
> mirroring - useful for backup purposes).
> 
> And if you are terrified of the possible consequences of a transient
> domain, there is another possibility for moving your data to a new disk,
> except that it forces you to convert to qcow2:
> 
> virsh snapshot-create-as $dom --no-metadata --disk-only \
>   --diskspec /ssd/image.raw,file=/hdd/image.qcow2
> virsh blockpull $dom --wait --verbose
> 
> and also has the drawback that if the guest quits in the middle of the
> blockpull, then you have to track both the original file and the
> snapshot wrapper - but at least blockpull is restartable from where it
> left off, for the next time the guest is running, whereas blockcopy has
> to start from scratch.

Eric,

For scripted live backups, which non-transient technique would you prefer:
1. snapshot-create-as followed by blockpull, which results in the original 
file being left as a standalone copy of the VM from that point in time; it
can then be copied off to a backup disk once blockpull completes
2. snapshot-create-as followed by copying the backing file (since it is now
read-only) and then using blockcommit to pull the interim changes back into
the original/backing file (and removing the snapshot file)

For #2 I suppose you could hash the backing file and the copy once it 
finishes to verify integrity of the backup copy.

Thanks,

Andrew