From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO5Kl-0004vm-RK for qemu-devel@nongnu.org; Sun, 22 May 2011 05:52:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QO5Kk-0001z1-8P for qemu-devel@nongnu.org; Sun, 22 May 2011 05:52:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO5Kj-0001yb-Px for qemu-devel@nongnu.org; Sun, 22 May 2011 05:52:26 -0400 Message-ID: <4DD8DCC9.2020203@redhat.com> Date: Sun, 22 May 2011 12:52:09 +0300 From: Dor Laor MIME-Version: 1.0 References: <4DC7EEB0.3040007@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , libvir-list , jes sorensen , Marcelo Tosatti , qemu-devel , Ayal Baron , Mingming Cao , Avi Kivity , Stefan Hajnoczi , Badari Pulavarty 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: - Run a (unrelated) VM and hotplug the snapshot as additional disk - Use v2v (libguestfs) - Boot the VM w/ RO - Plenty more > 5. Restore a VM from a snapshot > 6. Get the dirty blocks list (for incremental backup) It might be needed for additional proposes like efficient delta sync across sites or any other storage operation (dedup, etc) > > We've discussed image format-level approaches but I think the scope of > the API should cover several levels at which snapshots are > implemented: > 1. Image format - image file snapshot (Jes, Jagane) > 2. Host file system - ext4 and btrfs snapshots > 3. Storage system - LVM or SAN volume snapshots > > It will be hard to take advantage of more efficient host file system > or storage system snapshots if they are not designed in now. I agree but it can also be a chicken and the egg problem. Actually 1/2/3/5 are already working today regardless of live snapshots. > Is anyone familiar enough with the libvirt storage APIs to draft an > extension that adds snapshot support? I will take a stab at it if no > one else want to try it. I added libvirt-list and Ayal Baron from vdsm. What you're asking is even beyond snapshots, it's the whole management of VM images. Doing the above operations is simple but for enterprise virtualization solution you'll need to lock the NFS/SAN images, handle failures of VM/SAN/Mgmt, keep the snapshots info in mgmt DB, etc. Today it is managed by a combination of rhev-m/vdsm and libvirt. I agree it would have been nice to get such common single entry point interface. > > Stefan