<div dir="ltr">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?<div><br></div><div>=============================================================================================</div><div><div>root@farnsworth:/var/lib/libvirt/images# virsh -v</div><div>1.2.2</div></div><div><div>root@farnsworth:/var/lib/libvirt/images# qemu-system-x86_64 --version</div><div>QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.11), Copyright (c) 2003-2008 Fabrice Bellard</div><div>root@farnsworth:/var/lib/libvirt/images# qemu-img --version</div><div>qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard</div><div>usage: qemu-img command [command options]</div><div>QEMU disk image utility</div></div><div><div>=============================================================================================</div><div><br></div><div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 19, 2015 at 3:41 PM, Mathew Moon <span dir="ltr"><<a href="mailto:mathew.moon@vipaar.com" target="_blank">mathew.moon@vipaar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Eric,<div><br></div><div>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:</div><div><br></div><div>1. kill the VM</div><div>2. edit the VM's config</div><div>3. start the VM </div><div><br></div><div>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.</div><div><br></div><div>Any insights on how this could be accomplished using libvirt without rebooting?</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 19, 2015 at 2:20 PM, Eric Blake <span dir="ltr"><<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 05/19/2015 12:52 PM, Mathew Moon wrote:<br>
> Hi,<br>
><br>
> Is it possible to "pivot" to a new image without doing blockcopy or<br>
> blockpull?<br>
<br>
</span>No. Qemu does not support arbitrary reopening of a backing chain yet<br>
(even with the 'change-backing-file' QMP command, that is just rewriting<br>
contents of the qcow2 metadata, and not actually reopening the chain).<br>
The only way to pivot an image on a live guest is via blockcommit or<br>
blockcopy.  And one of the reasons that this is so is that pivoting only<br>
makes sense if you can guarantee that both source and destination have<br>
the same guest-visible contents - but without some block job that<br>
synchronizes two images just prior to the pivot and then cleanly flushes<br>
all pending I/O at the point of the pivot, you can't make that guarantee<br>
for any disk image that is being actively modified by guest execution.<br>
<br>
If you don't mind guest downtime, then you can save the guest state,<br>
modify the save file to edit in the updated file name, then restore from<br>
the saved state.<br>
<span><br>
> I know how to use snapshots and blockpull to create a new image<br>
> and pivot to using it live, but what I would like to do is to have a VM<br>
> switch from using imageA.qcow2 to image2.qcow2 while running. I don't see<br>
> why this wouldn't be possible since some of the existing libvirt tools can<br>
> do this when they are done. I would love to see an example from a bash<br>
> terminal as well as how it would be done using the python API.<br>
<br>
</span>blockpull is not the most efficient, and forces you to use a qcow2<br>
destination; but it was indeed the first way to accomplish a pivot from<br>
one disk to another.  But these days, with new enough libvirt and qemu,<br>
the ideal pivot uses snapshot-create, blockcopy, and active blockcommit,<br>
and lets you pivot to any destination format (does not have to be<br>
qcow2).  Roughly:<br>
<br>
$ # create a qcow2 wrapper<br>
$ virsh snapshot-create-as $dom --no-metadata --disk-only \<br>
  --diskspec vda,file=wrapA<br>
$ # copy the backing file to the pivot location, ideally \<br>
  taking advantage of faster-than-cp methods<br>
$ $your_cool_cp imageA imageB<br>
$ # create a destination qcow2 file<br>
$ qemu-img create -f qcow2 -obacking_file=imageB,backing_fmt=$fmt wrapB<br>
$ # block copy - note below that you may need to make $dom transient<br>
$ virsh blockcopy $dom vda wrapB --shallow --reuse-external --pivot \<br>
  --verbose<br>
$ # commit the wrapper back into the pivoted base<br>
$ virsh blockcommit $dom vda --shallow --active --verbose --pivot<br>
$ # delete the temporaries<br>
$ rm wrapA wrapB<br>
<br>
If $your_cool_cp is fast, such as taking advantage of a copy-on-write<br>
primitive of your storage array, then the overall operation can complete<br>
in under a second, because the amount of data stored in the temporary<br>
wrapA and copied over to wrapB and finally merged into imageB is so<br>
small that it doesn't take long (much faster than blockpull, which<br>
copies the entire disk contents regardless of how much changed in the<br>
meantime).<br>
<br>
qemu 2.4 will be adding persistent bitmaps, and the hope is that libvirt<br>
can take advantage of that to allow blockcopy to work without requiring<br>
a transient domain.  But in the meantime, you may have to use 'virsh<br>
dumpxml $dom > $file', 'virsh undefine $dom' prior to the blockcopy,<br>
then 'edit $file to updated name', 'virsh define $file' afterwards to<br>
restore it to persistent.<br>
<span><font color="#888888"><br>
--<br>
Eric Blake   eblake redhat com    <a href="tel:%2B1-919-301-3266" value="+19193013266" target="_blank">+1-919-301-3266</a><br>
Libvirt virtualization library <a href="http://libvirt.org" target="_blank">http://libvirt.org</a><br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>