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