From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgI6B-0003bA-UH for qemu-devel@nongnu.org; Mon, 11 Jul 2011 11:08:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QgI6A-00018Y-4i for qemu-devel@nongnu.org; Mon, 11 Jul 2011 11:08:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgI69-00018Q-M8 for qemu-devel@nongnu.org; Mon, 11 Jul 2011 11:08:37 -0400 Message-ID: <4E1B129B.5000806@redhat.com> Date: Mon, 11 Jul 2011 17:11:23 +0200 From: Kevin Wolf MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Taking live snapshots of running VMs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Ahmed M. Azab" Cc: jes sorensen , qemu-devel@nongnu.org, Stefan Hajnoczi Am 09.07.2011 00:24, schrieb Ahmed M. Azab: > Hi All, > > Is there a way to take a live memory snapshot of a running VM without > freezing or stopping this VM? > > I explored the Qemu code and documentation and I found two ways to > take a snapshot: > > 1-Using "savevm" Qemu monitor command, which freezes the VM for tens of seconds > 2-Using "migrate" and select the destination as a file, which forces > the machine to stop after the snapshot is saved. > > In production environments (where delaying the operations of a VM is > very critical), it is always useful to take memory snapshots to do > system analysis or forensics. I think Qemu should provide a way to > take a snapshot based on QOW technque of memory pages (same as the > QCOW disk snapshoting). > > If such technique does not exist, I am willing it devlop it myself, > but I wonder if the Qemu community will be interested to add my patch > to future versions. All the code that deals with memory is already there and used for migration. I think what you really need is a combination of savevm and live migration, such that you live migrate the VM state into the qcow2 image and when the migration has completed, you take a disk snapshot and continue the VM. It shouldn't be too hard to do this. All of the building blocks are there, they just need to be combined in the right way. I would be interested in a patch allowing this. Having said that, I think there are more variations that we'll want to support. Basically the dimensions that I see are: 1. Disk-only vs. complete VM state 2. Store VM state internally in qcow2 vs. an external file 3. Use internal vs. external disk snapshots Ideally, we would allow users to choose freely. For example, internal disk snapshot with external VM state is a combination that I think could be very useful. Kevin