qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file
Date: Mon, 19 Jan 2009 09:11:28 -0600
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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 <address@hidden>
---
 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   <address@hidden>
+ *  Uri Lublin        <address@hidden>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include <unistd.h>
+#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.

You could either use the posix-aio code to implement migration to a file or you could introduce a fork()'d process that wrote to a file from stdin. Although this is basically just exec dd of=.

It shouldn't be too hard to use posix-aio though. You just have to be clever about implementing the s->write op.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]