From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagane Sundar Subject: Re: snapmirror functionality using qcow2 and rsync? Date: Sun, 15 May 2011 10:16:07 -0700 Message-ID: <4DD00A57.70004@sundar.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Hajnoczi , "kvm@vger.kernel.org" , Jes Sorensen , Badari Pulavarty , Dor Laor To: Fred van Zwieten Return-path: Received: from qmta02.westchester.pa.hmc1.comcast.net ([76.96.53.9]:37272 "EHLO qmta02.westchester.pa.hmc1.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754729Ab1EORQL (ORCPT ); Sun, 15 May 2011 13:16:11 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Hello Fred, As Stefan points out, there is a lot of interest in such functionality. I am the author of a feature called Livebackup - which is aimed at solving exactly this problem - backup of live virtual machines. The additional constraint I place is that backup of the VM should be enabled regardless of the type of storage in use - file on local disk, file on NAS, LVM logical volume on local disk, LVM volume on an iSCSI volume. More information is at: http://wiki.qemu.org/Features/Livebackup I investigated the approach that you outline below - LVM snapshot followed by transfer of the blocks out of the VM host. The problem I ran into was that there was no easy way to identify the blocks that were modified since the last backup was taken. To the best of my knowledge, rsync uses checksums of entire files to determine whether a file was modified or not - in our use case the whole virtual disk is one single file, do rsync will not work well. One of the 'features' of Livebackup is that I chose to invent my own rudimentary protocol for transferring the blocks out of the VM host. iSCSI seems like a standard protocol that would suit the purpose; however it does not fit well with the architecture of Livebackup - I would probably need to implement an iSCSI target function inside Livebackup. Thanks, Jagane On 5/15/2011 7:11 AM, Stefan Hajnoczi wrote: > On Sun, May 15, 2011 at 1:16 PM, Fred van Zwieten wrote: >> Background: >> NetApp Snashot functionality gives you application consistent >> snapshots of data. Just inform the app a snapshot is about to be made, >> depending on the app, it needs to go in to some sort of backup mode, >> of just stop and flush outstanding I/O. Next, a snapshot is made and >> everything just runs on. Because of the underlying WAFL filesystem >> design, the snapshot always points to the blocks at the time of the >> creation without needing to do any COW. >> >> Layered on top op this functionality is SnapMirror, where the delta >> between this snapshot and a previous snapshot (both being static in >> nature), is asynchronously replicated to a second system. There, this >> delta is applied to a copy of the disk as a local snapshot. >> >> This setup gives you application consistent data disks on a remote >> location as a form of disaster tolerancy. The RPO is the >> snapshot/snapmirror frequency. >> >> KVM: >> My question is rather simple. Could something like this be implemented >> with kvm-img and rsync and/or lvm? I've played with the backing_file >> option, but this means I have to shutdown the vm a boot is on the new >> file to let this work. > This recent thread might interest you: > http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg00733.html > > Basically you have to cobble it together yourself at the moment but > there is activity around live snapshots and dirty block tracking, so > hopefully they will be available as APIs in the future. > > Stefan