From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPFWN-00046I-3M for qemu-devel@nongnu.org; Tue, 20 Jan 2009 07:15:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPFWL-00045L-6j for qemu-devel@nongnu.org; Tue, 20 Jan 2009 07:15:53 -0500 Received: from [199.232.76.173] (port=32784 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPFWK-000455-Jd for qemu-devel@nongnu.org; Tue, 20 Jan 2009 07:15:52 -0500 Received: from mx2.redhat.com ([66.187.237.31]:55806) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPFWK-00081F-6r for qemu-devel@nongnu.org; Tue, 20 Jan 2009 07:15:52 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0KCFpCi023718 for ; Tue, 20 Jan 2009 07:15:51 -0500 Message-ID: <4975C074.5010300@redhat.com> Date: Tue, 20 Jan 2009 14:15:48 +0200 From: Uri Lublin MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file References: <1232324325-25060-1-git-send-email-uril@redhat.com> <49749820.2070209@codemonkey.ws> <20090120111530.GJ6004@redhat.com> In-Reply-To: <20090120111530.GJ6004@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org Daniel P. Berrange wrote: > On Mon, Jan 19, 2009 at 09:11:28AM -0600, Anthony Liguori wrote: >> Uri Lublin wrote: >>> Migration to file, reuses migration-to-fd. >>> Migration from file, uses qemu-fopen directly. >>> >>> The saved state-file should be used only once and removed (or used >>> with -snapshot, or a the disk-image should be copied), as the >>> disk image is not saved, only the VM state. >>> >>> Also there is not point of doing a _live_ migration to file (except >>> for debugging migration code), so I recommend to stop the VM before >>> migrating its state to a file. >>> >>> An advantage migration-to-file over savevm/loadvm is that for the latter >>> a qcow2 is a requirement, while the former works for any image-format. >>> >>> Signed-off-by: Uri Lublin >>> --- >>> >> The migration code assumes that the file descriptor used is >> non-blocking. In general, open() on a file system cannot produce a >> non-blocking file descriptor. > > Does it matter if it blocks though ? Migrating to a file is not > "live" migration anyway, so if we happen to block the rest of the > QEMU event loop during course of writing to the file it doesn't seem > too serious. Or is there some scenario which badly breaks with blocking > writes even for non-live usage ? > I first thought it's not that important too. But it may be less than optimal, especially if qemu does not respond to monitor commands, which may affect management applications. What does libvirt do when qemu does not respond to a monitor command ? Uri.