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@farnsworth:/var/lib/libvirt/images# virsh -v 1.2.2 root@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@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.m...@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 <ebl...@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 >> >> >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
