From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHVzi-00055e-Cr for qemu-devel@nongnu.org; Mon, 18 Mar 2013 05:04:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHVzg-0000Su-Qo for qemu-devel@nongnu.org; Mon, 18 Mar 2013 05:04:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHVzg-0000Sn-HU for qemu-devel@nongnu.org; Mon, 18 Mar 2013 05:04:36 -0400 Date: Mon, 18 Mar 2013 10:04:30 +0100 From: Kevin Wolf Message-ID: <20130318090430.GB2476@dhcp-200-207.str.redhat.com> References: <5142CCB6.7000004@linux.vnet.ibm.com> <20130315145100.GA17187@stefanha-thinkpad.redhat.com> <5146B6F2.3030004@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5146B6F2.3030004@linux.vnet.ibm.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] qmp interface for save vmstate to image List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: Juan Quintela , Stefan Hajnoczi , qemu-devel , Paolo Bonzini , Dietmar Maurer Am 18.03.2013 um 07:40 hat Wenchao Xia geschrieben: > =E4=BA=8E 2013-3-15 22:51, Stefan Hajnoczi =E5=86=99=E9=81=93: > > On Fri, Mar 15, 2013 at 03:24:38PM +0800, Wenchao Xia wrote: > >> I'd like to add a new way to save vmstate, which will based on th= e > >> migration thread, but will write contents to block images, instead > >> of fd as stream. Following is the method to add API: > >=20 > > Hi Wenchao, > > What use cases are there besides saving vmstate to a raw image? > >=20 > > I'm curious if you're proposing this since there is no "file:" URI or > > because you really want to do things like saving vmstate into a qcow2 > > file or over NBD. > >=20 > > Stefan > >=20 > Hi, Stefan > Most used cases would be "raw" and "qcow2", which is flex and can be > chosen by user. In this way, existing block layer feature in qemu can > be used, such as tagging zeros. I haven't check the buffer/cache status > in qemu block layer, but if there is, it can also benefit. > User can specify "raw" or "qcow2" according to host configuration, If > there is dedicated storage components underlining, he can use "raw" to > skip qemu's block layer. Oh, seems I misread this then. I thought this was about internal live snapshots, which is a feature that I consider really useful. I'm not so sure if saving the VM state as the disk contents of a qcow2 image is really helpful. If zero clusters help a lot, then there's clearly something to improve in the migration protocol, because it shouldn't send so many zeros in the first place. Kevin