[libvirt-users] Pivot without copy

Tue May 19 21:06:20 UTC 2015

It seems that my version of libvirt does not support the flags that yours
does either. I have the latest version from the Ubuntu repos and am running
14.04. What version are you running and do you know if these features
depend on libvirt, or qemu-img to be upgraded?

=============================================================================================
root at farnsworth:/var/lib/libvirt/images# virsh -v
1.2.2
root at farnsworth:/var/lib/libvirt/images# qemu-system-x86_64 --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.11), Copyright (c)
2003-2008 Fabrice Bellard
root at farnsworth:/var/lib/libvirt/images# qemu-img --version
qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard
usage: qemu-img command [command options]
QEMU disk image utility
=============================================================================================

On Tue, May 19, 2015 at 3:41 PM, Mathew Moon <mathew.moon at vipaar.com> wrote:

> 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/4e5c616b/attachment.htm>