[libvirt-users] Pivot without copy

[Mathew Moon]

Hi Eric,

Thanks for the info. I see the value in this, but it isn't quite what I was
looking for. Basically what I want to do is to switch between snapshots
quickly. For instance, I am currently working on designing a HA SQL
implementation with failover. So right now I have 5 VM's running postgresql
as a replication group. I am trying a lot of different things and often
have to take a snapshot of all 5 VM's, do some work, and then to revert to
the previous snapshot I have to:

1. kill the VM
2. edit the VM's config
3. start the VM

What I would like is to be able to "pivot" the "current" image to be the
previous snapshot (in most cases). I understand that if this were possible
then there would be applications crash because something on disk doesn't
jive with what is in memory, but I am ok with that, I just want to get my
databases back to "square one" quickly after something in the procedure I
am working on foo bar's my db and it is replicated to 4 other nodes.

Any insights on how this could be accomplished using libvirt without
rebooting?


On Tue, May 19, 2015 at 2:20 PM, Eric Blake <eblake at redhat.com> wrote:

> On 05/19/2015 12:52 PM, Mathew Moon wrote:
> > Hi,
> >
> > Is it possible to "pivot" to a new image without doing blockcopy or
> > blockpull?
>
> No. Qemu does not support arbitrary reopening of a backing chain yet
> (even with the 'change-backing-file' QMP command, that is just rewriting
> contents of the qcow2 metadata, and not actually reopening the chain).
> The only way to pivot an image on a live guest is via blockcommit or
> blockcopy.  And one of the reasons that this is so is that pivoting only
> makes sense if you can guarantee that both source and destination have
> the same guest-visible contents - but without some block job that
> synchronizes two images just prior to the pivot and then cleanly flushes
> all pending I/O at the point of the pivot, you can't make that guarantee
> for any disk image that is being actively modified by guest execution.
>
> If you don't mind guest downtime, then you can save the guest state,
> modify the save file to edit in the updated file name, then restore from
> the saved state.
>
> > I know how to use snapshots and blockpull to create a new image
> > and pivot to using it live, but what I would like to do is to have a VM
> > switch from using imageA.qcow2 to image2.qcow2 while running. I don't see
> > why this wouldn't be possible since some of the existing libvirt tools
> can
> > do this when they are done. I would love to see an example from a bash
> > terminal as well as how it would be done using the python API.
>
> blockpull is not the most efficient, and forces you to use a qcow2
> destination; but it was indeed the first way to accomplish a pivot from
> one disk to another.  But these days, with new enough libvirt and qemu,
> the ideal pivot uses snapshot-create, blockcopy, and active blockcommit,
> and lets you pivot to any destination format (does not have to be
> qcow2).  Roughly:
>
> $ # create a qcow2 wrapper
> $ virsh snapshot-create-as $dom --no-metadata --disk-only \
>   --diskspec vda,file=wrapA
> $ # copy the backing file to the pivot location, ideally \
>   taking advantage of faster-than-cp methods
> $ $your_cool_cp imageA imageB
> $ # create a destination qcow2 file
> $ qemu-img create -f qcow2 -obacking_file=imageB,backing_fmt=$fmt wrapB
> $ # block copy - note below that you may need to make $dom transient
> $ virsh blockcopy $dom vda wrapB --shallow --reuse-external --pivot \
>   --verbose
> $ # commit the wrapper back into the pivoted base
> $ virsh blockcommit $dom vda --shallow --active --verbose --pivot
> $ # delete the temporaries
> $ rm wrapA wrapB
>
> If $your_cool_cp is fast, such as taking advantage of a copy-on-write
> primitive of your storage array, then the overall operation can complete
> in under a second, because the amount of data stored in the temporary
> wrapA and copied over to wrapB and finally merged into imageB is so
> small that it doesn't take long (much faster than blockpull, which
> copies the entire disk contents regardless of how much changed in the
> meantime).
>
> qemu 2.4 will be adding persistent bitmaps, and the hope is that libvirt
> can take advantage of that to allow blockcopy to work without requiring
> a transient domain.  But in the meantime, you may have to use 'virsh
> dumpxml $dom > $file', 'virsh undefine $dom' prior to the blockcopy,
> then 'edit $file to updated name', 'virsh define $file' afterwards to
> restore it to persistent.
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20150519/8ea9e2b7/attachment.htm>