+/* A peculiarity of qemu's vmchannel implementation is that both sides
+ * connect to qemu, ie:
+ *
+ * libguestfs --- connect --> qemu <-- connect --- daemon
+ * (host) (guest)
+ *
+ * This has several implications: (1) qemu creates the Unix socket, so
+ * we have to wait for it to do that. (2) we have to arrange for the
+ * daemon to send a "hello" message which we also wait for.
+ *
+ * At any time during this, the qemu subprocess might run slowly, die
+ * or hang (it's very prone to just hanging if the BIOS fails for any
+ * reason or if the kernel cannot be found to boot from).
+ *
+ * The only realistic way to handle this is, unfortunately, using
+ * timeouts, also checking if the qemu subprocess is still alive.
+ *
+ * We could do better here by monitoring the Linux kernel log messages
+ * (via the serial console, which is currently just redirected to a
+ * log file) and seeing if the Linux guest is making progress. (XXX)
+ */
+
+#define QEMU_SOCKET_TIMEOUT 5 /* How long we wait for qemu to make
+ * the socket. This should be very quick.
+ */
+#define DAEMON_TIMEOUT 60 /* How long we wait for guest to boot
+ * and start the daemon. This could take
+ * a potentially long time, and is very
+ * sensitive to the overall load on the host.
+ */
+
+static int wait_ready (guestfs_h *g);