From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBMFK-0002be-I7 for qemu-devel@nongnu.org; Fri, 01 Mar 2013 04:27:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBMFJ-0001qI-Bo for qemu-devel@nongnu.org; Fri, 01 Mar 2013 04:27:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBMFJ-0001qE-2T for qemu-devel@nongnu.org; Fri, 01 Mar 2013 04:27:17 -0500 Date: Fri, 1 Mar 2013 10:27:10 +0100 From: Kevin Wolf Message-ID: <20130301092710.GB2461@dhcp-200-207.str.redhat.com> References: <1362038985-19008-1-git-send-email-xiawenc@linux.vnet.ibm.com> <20130228105035.GE2429@dhcp-200-207.str.redhat.com> <513013F0.2030007@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <513013F0.2030007@linux.vnet.ibm.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: stefanha@gmail.com, aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com Am 01.03.2013 um 03:35 hat Wenchao Xia geschrieben: > =E4=BA=8E 2013-2-28 18:50, Kevin Wolf =E5=86=99=E9=81=93: > >Am 28.02.2013 um 09:09 hat Wenchao Xia geschrieben: > >>This version have following limitation: > >> 1 in patch 3 only dirty page got written, clean page is not touche= d, so > >>it will have trouble when savevm to an old internal snapshot, which > >>will be fixed later if this approach seems OK. > > > >Basically you need a bdrv_zero_vmstate(), right? I think this would > Yes, an API to initialize the data at the beginning, or just write 4K > zero in the progress.... >=20 > >actually be a bug fix, because snapshots might today get references to > >unused VM state clusters that are just leftovers from the last snapsho= t. > > > In a qcow2 file that have snapA, if user type "savevm snapA", then > qemu will delete old snapA and then create new snapA. > Do you mean that new snapA and old snapA may use the same cluster > that is not cleaned up as zeros? I guess this brings no trouble to old > stream savevm, but will brings trouble to plane savevm in this patch. > If so, I think yes this bug fix can solve the problem. The scenario I'm thinking of is something like: 1. (qemu) savevm A 2. (qemu) quit 3. qemu-img snapshot -c B test.qcow2 4. qemu-img snapshot -d A test.qcow2 Step 1 creates a snapshot from a running VM, so it writes a lot of VM state data to the image. Step 3 creates another snapshot, however outside of a running qemu, so without VM state. It wrongly gets a reference to all VM state clusters of A, which haven't been overwritten or discarded since snapshot A was taken. When deleting A in step 4, the clusters cannot be freed because they are still referenced by B (which doesn't need them at all) Kevin