OK -- thanks. We are using LVMs on the bricks, but I'm not sure that's the way I want to go. Would the file snaps in 3.5 be my best option? I'm guessing that should be FUSE / libgfapi agnostic as well, correct? Thanks. On 11/18/2013 01:52 AM, Stefan Hajnoczi wrote: > On Fri, Nov 15, 2013 at 6:48 PM, Nicholas Majeran > <nmajeran at suntradingllc.com> wrote: >> I am running a KVM test cluster on Fedora 19 using gluster + libgfapi as a >> network backend for my QCOW2 images. >> This configuration precludes me from using virsh's backup features provided >> in Fedora and thus I am doing "live snapshots" by executing: >> >> # perform internal snapshot on qcow2 using FUSE mount to gluster: >> qemu-img snapshot -c snapname /gluster/test.qcow2 >> >> # convert the snapshot to an external file for archiving: >> qemu-img convert -s snapname /gluster/test.qcow2 >> /gluster-backup/test.qcow2.snapshot >> >> My Question: >> >> 1. Is there any blocking or locking issues I should be concerned about while >> doing snapshot's or converts? >> >> 2. I know this leaves my snapshot in an inconsistent state...but is this an >> incorrect use of the qemu/qcow2 tools? > Accessing the image file from another process while the VM is running > is not support and could corrupt the image file. > >> 3. Is there a better way to do this via gluster / gfapi that I'm missing? > If you use LVM on the bricks you can use the block device translator > (bd_map) which supports LVM snapshots. > > Stefan -- Nick Majeran Sun Trading LLC 312-229-9608
