From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call agenda for Oct 19 Date: Wed, 20 Oct 2010 08:05:58 -0500 Message-ID: <4CBEE936.4010305@codemonkey.ws> References: <394180839.46171287507268868.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4CBDD0D0.6050101@codemonkey.ws> <4CBEB3C8.5070601@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ayal Baron , chrisw@redhat.com, kvm@vger.kernel.org, Juan Quintela , dlaor@redhat.com, qemu-devel@nongnu.org, Chris Wright , "Venkateswararao Jujjuri (JV)" To: Kevin Wolf Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:61801 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750891Ab0JTNGB (ORCPT ); Wed, 20 Oct 2010 09:06:01 -0400 Received: by qwa26 with SMTP id 26so2308447qwa.19 for ; Wed, 20 Oct 2010 06:06:01 -0700 (PDT) In-Reply-To: <4CBEB3C8.5070601@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/20/2010 04:18 AM, Kevin Wolf wrote: > Am 19.10.2010 19:09, schrieb Anthony Liguori: > >> On 10/19/2010 11:54 AM, Ayal Baron wrote: >> >>> ----- "Anthony Liguori" wrote: >>> >>> >>> >>>> On 10/19/2010 07:48 AM, Dor Laor wrote: >>>> >>>> >>>>> On 10/19/2010 04:11 AM, Chris Wright wrote: >>>>> >>>>> >>>>>> * Juan Quintela (quintela@redhat.com) wrote: >>>>>> >>>>>> >>>>>>> Please send in any agenda items you are interested in covering. >>>>>>> >>>>>>> >>>>>> - 0.13.X -stable handoff >>>>>> - 0.14 planning >>>>>> - threadlet work >>>>>> - virtfs proposals >>>>>> >>>>>> >>>>>> >>>>> - Live snapshots >>>>> - We were asked to add this feature for external qcow2 >>>>> images. Will simple approach of fsync + tracking each requested >>>>> backing file (it can be per vDisk) and re-open the new image >>>>> >>>>> >>>> would >>>> >>>> >>>>> be accepted? >>>>> >>>>> >>>> I had assumed that this would involve: >>>> >>>> qemu -hda windows.img >>>> >>>> (qemu) snapshot ide0-disk0 snap0.img >>>> >>>> 1) create snap0.img internally by doing the equivalent of `qemu-img >>>> create -f qcow2 -b windows.img snap0.img' >>>> 2) bdrv_flush('ide0-disk0') >>>> 3) bdrv_open(snap0.img) >>>> 4) bdrv_close(windows.img) >>>> 5) rename('windows.img', 'windows.img.tmp') >>>> 6) rename('snap0.img', 'windows.img') >>>> 7) rename('windows.img.tmp', 'snap0.img') >>>> >>>> >>> All the rename logic assumes files, need to take into account devices as well (namely LVs) >>> >>> >> Sure, just s/rename/lvrename/g. >> > That would mean that you need to have both backing file and new COW > image on LVs. > Yeah, I guess there are two options. You could force a user to create the new leaf image or you could make the command take a blockdev spec excluding the backing_file and automatically insert the backing_file attribute into the spec before creating the bs. >> The renaming step can be optional and a management tool can take care of >> that. It's really just there for convenience since the user expectation >> is that when you give a name of a snapshot, that the snapshot is >> reflected in that name not that the new in-use image is that name. >> > I think that depends on the terminology you use. > > If you call it doing a snapshot, then probably people expect that the > snapshot is a new file and they continue to work on the same file (and > they may not understand that removing the snapshot destroys the "main" > image). > > If you call it something like creating a new branch, they will expect > that the old file stays as it is and they create something new on top of > that. > > So maybe we shouldn't start doing renames (which we cannot do for > anything but files anyway, consider not only LVs, but also nbd or http > backends), but rather think of a good name for the operation. > Yeah, that's a reasonable point. Regards, Anthony Liguori > Kevin >