return 0;
}
-int
+size_t
guestfs___checkpoint_cmdline (guestfs_h *g)
{
return g->cmdline_size;
}
void
-guestfs___rollback_cmdline (guestfs_h *g, int pos)
+guestfs___rollback_cmdline (guestfs_h *g, size_t pos)
{
- int i;
+ size_t i;
assert (g->cmdline_size >= pos);
- for (i = g->cmdline_size - 1; i >= pos; --i)
+ for (i = pos; i < g->cmdline_size; ++i)
free (g->cmdline[i]);
g->cmdline_size = pos;
char **
guestfs__debug_cmdline (guestfs_h *g)
{
- int i;
+ size_t i;
char **r;
if (g->cmdline == NULL) {
/* Start the clock ... */
gettimeofday (&g->launch_t, NULL);
+ guestfs___launch_send_progress (g, 0);
/* Locate and/or build the appliance. */
char *kernel = NULL, *initrd = NULL, *appliance = NULL;
if (guestfs___build_appliance (g, &kernel, &initrd, &appliance) == -1)
return -1;
+ guestfs___launch_send_progress (g, 3);
+
if (g->verbose)
guestfs___print_timestamped_message (g, "begin testing qemu features");
if (qemu_supports (g, "-nodefconfig"))
add_cmdline (g, "-nodefconfig");
- /* qemu sometimes needs this option to enable hardware
- * virtualization, but some versions of 'qemu-kvm' will use KVM
- * regardless (even where this option appears in the help text).
- * It is rumoured that there are versions of qemu where supplying
- * this option when hardware virtualization is not available will
- * cause qemu to fail, so we we have to check at least that
- * /dev/kvm is openable. That's not reliable, since /dev/kvm
- * might be openable by qemu but not by us (think: SELinux) in
- * which case the user would not get hardware virtualization,
- * although at least shouldn't fail. A giant clusterfuck with the
- * qemu command line, again.
+ /* The qemu -machine option (added 2010-12) is a bit more sane
+ * since it falls back through various different acceleration
+ * modes, so try that first (thanks Markus Armbruster).
*/
- if (qemu_supports (g, "-enable-kvm") &&
- is_openable (g, "/dev/kvm", O_RDWR))
- add_cmdline (g, "-enable-kvm");
+ if (qemu_supports (g, "-machine")) {
+ add_cmdline (g, "-machine");
+ add_cmdline (g, "accel=kvm:tcg");
+ } else {
+ /* qemu sometimes needs this option to enable hardware
+ * virtualization, but some versions of 'qemu-kvm' will use KVM
+ * regardless (even where this option appears in the help text).
+ * It is rumoured that there are versions of qemu where supplying
+ * this option when hardware virtualization is not available will
+ * cause qemu to fail, so we we have to check at least that
+ * /dev/kvm is openable. That's not reliable, since /dev/kvm
+ * might be openable by qemu but not by us (think: SELinux) in
+ * which case the user would not get hardware virtualization,
+ * although at least shouldn't fail. A giant clusterfuck with the
+ * qemu command line, again.
+ */
+ if (qemu_supports (g, "-enable-kvm") &&
+ is_openable (g, "/dev/kvm", O_RDWR))
+ add_cmdline (g, "-enable-kvm");
+ }
/* Newer versions of qemu (from around 2009/12) changed the
* behaviour of monitors so that an implicit '-monitor stdio' is
close (wfd[1]);
close (rfd[0]);
+ /* Stdin. */
if (dup (wfd[0]) == -1) {
dup_failed:
perror ("dup failed");
_exit (EXIT_FAILURE);
}
+ /* Stdout. */
if (dup (rfd[1]) == -1)
goto dup_failed;
close (rfd[1]);
}
-#if 0
- /* Set up a new process group, so we can signal this process
- * and all subprocesses (eg. if qemu is really a shell script).
- */
- setpgid (0, 0);
-#endif
+ /* Put qemu in a new process group. */
+ if (g->pgroup)
+ setpgid (0, 0);
setenv ("LC_ALL", "C", 1);
pid_t qemu_pid = g->pid;
pid_t parent_pid = getppid ();
+ /* It would be nice to be able to put this in the same process
+ * group as qemu (ie. setpgid (0, qemu_pid)). However this is
+ * not possible because we don't have any guarantee here that
+ * the qemu process has started yet.
+ */
+ if (g->pgroup)
+ setpgid (0, 0);
+
/* Writing to argv is hideously complicated and error prone. See:
* http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/ps_status.c?rev=1.33.2.1;content-type=text%2Fplain
*/
goto cleanup1;
}
+ guestfs___launch_send_progress (g, 12);
+
return 0;
cleanup1:
return -1;
}
+/* launch (of the ordinary appliance) generates approximate progress
+ * messages. Currently these are defined as follows:
+ *
+ * 0 / 12: launch clock starts
+ * 3 / 12: appliance created
+ * 6 / 12: detected that guest kernel started
+ * 9 / 12: detected that /init script is running
+ * 12 / 12: launch completed successfully
+ *
+ * Notes:
+ * (1) This is not a documented ABI and the behaviour may be changed
+ * or removed in future.
+ * (2) Messages are only sent if more than 5 seconds has elapsed
+ * since the launch clock started.
+ * (3) There is a gross hack in proto.c to make this work.
+ */
+void
+guestfs___launch_send_progress (guestfs_h *g, int perdozen)
+{
+ struct timeval tv;
+
+ gettimeofday (&tv, NULL);
+ if (timeval_diff (&g->launch_t, &tv) >= 5000) {
+ guestfs_progress progress_message =
+ { .proc = 0, .serial = 0, .position = perdozen, .total = 12 };
+
+ guestfs___progress_message_callback (g, &progress_message);
+ }
+}
+
/* Return the location of the tmpdir (eg. "/tmp") and allow users
* to override it at runtime using $TMPDIR.
* http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
git.annexia.org / libguestfs.git / blobdiff