QEMU-KVM-libgfapi question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux