From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPEa7-0004ZN-4p for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:15:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPEa4-0004Wr-Lk for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:15:40 -0500 Received: from [199.232.76.173] (port=51486 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPEa4-0004VJ-Bn for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:15:40 -0500 Received: from mx1.redhat.com ([66.187.233.31]:57919) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPEa2-0001iS-6i for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:15:38 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n0KBFWiV018025 for ; Tue, 20 Jan 2009 06:15:32 -0500 Date: Tue, 20 Jan 2009 11:15:30 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file Message-ID: <20090120111530.GJ6004@redhat.com> References: <1232324325-25060-1-git-send-email-uril@redhat.com> <49749820.2070209@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49749820.2070209@codemonkey.ws> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Uri Lublin 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 > >--- > > Makefile | 2 +- > > migration-file.c | 127 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > migration.c | 4 ++ > > migration.h | 5 ++ > > 4 files changed, 137 insertions(+), 1 deletions(-) > > create mode 100644 migration-file.c > > > >diff --git a/Makefile b/Makefile > >index 8cbdcda..7e0e6f2 100644 > >--- a/Makefile > >+++ b/Makefile > >@@ -81,7 +81,7 @@ OBJS+=usb.o usb-hub.o usb-$(HOST_USB).o usb-hid.o > >usb-msd.o usb-wacom.o > > OBJS+=usb-serial.o usb-net.o > > OBJS+=sd.o ssi-sd.o > > OBJS+=bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o bt-hci.o bt-hid.o > > usb-bt.o > >-OBJS+=buffered_file.o migration.o migration-tcp.o net.o qemu-sockets.o > >+OBJS+=buffered_file.o migration.o migration-tcp.o migration-file.o net.o > >qemu-sockets.o > > OBJS+=qemu-char.o aio.o net-checksum.o savevm.o cache-utils.o > > > > ifdef CONFIG_BRLAPI > >diff --git a/migration-file.c b/migration-file.c > >new file mode 100644 > >index 0000000..5cde3e2 > >--- /dev/null > >+++ b/migration-file.c > >@@ -0,0 +1,127 @@ > >+/* > >+ * QEMU live migration > >+ * > >+ * Copyright IBM, Corp. 2008 > >+ * Red Hat, Inc. 2008 > >+ * > >+ * Authors: > >+ * Anthony Liguori > >+ * Uri Lublin > >+ * > >+ * This work is licensed under the terms of the GNU GPL, version 2. See > >+ * the COPYING file in the top-level directory. > >+ * > >+ */ > >+ > >+#include > >+#include "qemu-common.h" > >+#include "migration.h" > >+#include "sysemu.h" > >+#include "console.h" > >+#include "block.h" > >+ > >+//#define DEBUG_MIGRATION_FILE > >+ > >+#ifdef DEBUG_MIGRATION_FILE > >+#define dprintf(fmt, ...) \ > >+ do { printf("migration-file: " fmt, ## __VA_ARGS__); } while (0) > >+#else > >+#define dprintf(fmt, ...) \ > >+ do { } while (0) > >+#endif > >+ > >+static int file_close(FdMigrationState *s) > >+{ > >+ close(s->fd); > >+} > >+ > >+static int file_errno(FdMigrationState *s) > >+{ > >+ return errno; > >+} > >+ > >+static int file_write(FdMigrationState *s, const void * buf, size_t size) > >+{ > >+ return write(s->fd, buf, size); > >+} > >+ > >+MigrationState *file_start_outgoing_migration(const char *filename, > >+ int64_t bandwidth_limit, > >+ int async) > >+{ > >+ FdMigrationState *s; > >+ int fd; > >+ > >+ s = qemu_mallocz(sizeof(*s)); > >+ if (s == NULL) { > >+ perror("file_migration: qemu_mallocz failed"); > >+ term_printf("file_migration: qemu_mallocz failed"); > >+ goto err1; > >+ } > >+ > >+ fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0600); > >+ if (fd < 0) { > >+ perror("file_migration: failed to open filename"); > >+ term_printf("file_migration: failed to open filename %s\n", > >filename); > >+ goto err2; > >+ } > > > > 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 ? Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|