Re: [libvirt-users] Pivot without copy

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(a)redhat.com&gt; 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 > >