From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIfx9-0007gx-6f for qemu-devel@nongnu.org; Thu, 21 Mar 2013 09:54:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIfx4-0003Gc-GS for qemu-devel@nongnu.org; Thu, 21 Mar 2013 09:54:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIfx4-0003GO-7a for qemu-devel@nongnu.org; Thu, 21 Mar 2013 09:54:42 -0400 Message-ID: <514B10BE.2020000@redhat.com> Date: Thu, 21 Mar 2013 14:53:02 +0100 From: Pavel Hrdina MIME-Version: 1.0 References: <5142CCB6.7000004@linux.vnet.ibm.com> <51471686.3030505@redhat.com> <514AABFC.1030605@linux.vnet.ibm.com> <514AF393.8030109@redhat.com> <20130321133802.GA15276@stefanha-thinkpad.redhat.com> <514B0E3F.5070309@redhat.com> In-Reply-To: <514B0E3F.5070309@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Paolo Bonzini Cc: Kevin Wolf , Juan Quintela , Stefan Hajnoczi , qemu-devel , Dietmar Maurer , Wenchao Xia On 03/21/2013 02:42 PM, Paolo Bonzini wrote: > Il 21/03/2013 14:38, Stefan Hajnoczi ha scritto: >> There already is a guest RAM cloning mechanism: fork the QEMU process. >> Then you have a copy-on-write guest RAM. >> >> In a little more detail: >> >> 1. save non-RAM device state >> 2. quiesce QEMU to a state that is safe for forking >> 3. create an EventNotifier for live savevm completion signal >> 4. fork and pass completion EventNotifier to child >> 5. parent continues running VM >> 6. child performs vmsave of copy-on-write guest RAM >> 7. child signals completion EventNotifier and terminates >> 8. parent raises live savevm completion QMP event > > Forking a threaded program is not so easy, but it could be done if the > child is very simple and only uses syscalls to communicate back with the > parent: > > 1. save non-RAM device state > 2. quiesce QEMU to a state that is safe for forking > 3. create a memory map and a pipe > 4. fork and pass the write end of the pipe to the child > 5. parent continues running VM > 6. child reads the memory map and writes data to the pipe > 7. parent copies data from the pipe to the migration stream > 8. child exits, parent raises live savevm completion QMP event > > Paolo > As I just wrote to Stefan, I've already heard the fork idea. I was trying to do it without forking the QEMU, but it will need support from KVM and it could be harder to do instead of forking the QEMU. I'll start working on this. Thanks Paolo Pavel