From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQ0BX-0008P4-M3 for qemu-devel@nongnu.org; Fri, 27 May 2011 12:46:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QQ0BW-0005ad-J9 for qemu-devel@nongnu.org; Fri, 27 May 2011 12:46:51 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:47426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQ0BW-0005aV-Fm for qemu-devel@nongnu.org; Fri, 27 May 2011 12:46:50 -0400 Received: by gwb19 with SMTP id 19so951797gwb.4 for ; Fri, 27 May 2011 09:46:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <4DC7EEB0.3040007@redhat.com> <4DD8DCC9.2020203@redhat.com> Date: Fri, 27 May 2011 17:46:49 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jagane Sundar Cc: Kevin Wolf , Anthony Liguori , dlaor@redhat.com, libvir-list , jes sorensen , Marcelo Tosatti , qemu-devel , Ayal Baron , Mingming Cao , Avi Kivity , Stefan Hajnoczi , Badari Pulavarty On Mon, May 23, 2011 at 2:02 PM, Stefan Hajnoczi wrote= : > On Sun, May 22, 2011 at 10:52 AM, Dor Laor wrote: >> On 05/20/2011 03:19 PM, Stefan Hajnoczi wrote: >>> >>> I'm interested in what the API for snapshots would look like. >>> Specifically how does user software do the following: >>> 1. Create a snapshot >>> 2. Delete a snapshot >>> 3. List snapshots >>> 4. Access data from a snapshot >> >> There are plenty of options there: >> =A0- Run a (unrelated) VM and hotplug the snapshot as additional disk > > This is the backup appliance VM model and makes it possible to move > the backup application to where the data is (or not, if you have a SAN > and decide to spin up the appliance VM on another host). =A0This should > be perfectly doable if snapshots are "volumes" at the libvirt level. > > A special-case of the backup appliance VM is using libguestfs to > access the snapshot from the host. =A0This includes both block-level and > file system-level access along with OS detection APIs that libguestfs > provides. > > If snapshots are "volumes" at the libvirt level, then it is also > possible to use virStorageVolDownload() to stream the entire snapshot > through libvirt: > http://libvirt.org/html/libvirt-libvirt.html#virStorageVolDownload > > Summarizing, here are three access methods that integrate with libvirt > and cover many use cases: > > 1. Backup appliance VM. =A0Add a readonly snapshot volume to a backup > appliance VM. =A0If shared storage (e.g. SAN) is available then the > appliance can be run on any host. =A0Otherwise the appliance must run on > the same host that the snapshot resides on. > > 2. Libguestfs client on host. =A0Launch libguestfs with the readonly > snapshot volume. =A0The backup application runs directly on the host, it > has both block and file system access to the snapshot. > > 3. Download the snapshot to a remote host for backup processing. =A0Use > the virStorageVolDownload() API to download the snapshot onto a > libvirt client machine. =A0Dirty block tracking is still useful here > since the virStorageVolDownload() API supports > arguments. Jagane, What do you think about these access methods? What does your custom protocol integrate with today - do you have a custom non-libvirt KVM management stack? Stefan