On 26/11/2014 20:51, M A Young wrote:

Migrations with xl migrate --debug will fail because debugging information from the receiving process is written to the stdout channel. This channel is also used for status messages so the migration will fail as the sending process receives an unexpected message. This patch moves the debugging information to the stderr channel.

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

Ah yes - that will do.

The whole info/error/debug handling here is a mess. Amongst other issues, it is not possible to distinguish whether libxc logging messages are coming from the sending or receiving side, without judging the context from the text itself.

Use stderr for debugging messages for xl migrate --debug as stdout is used
for status messages.

--- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000 +0100
+++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +0000
@@ -383,7 +383,7 @@

Sadly, changing printf_info() like this has an unintended knock-on effect to create_domain() (xl create, migrate-recevive, restore) and xl config-update. I think you might have to pass FILE pointers all the way through.

                         libxl_domain_config *d_config)
 {
     if (output_format == OUTPUT_FORMAT_SXP)
-        return printf_info_sexp(domid, d_config);
+        return printf_info_sexp(domid, d_config, stderr);
 
     const char *buf;
     libxl_yajl_length len = 0;
@@ -404,7 +404,7 @@
     if (s != yajl_gen_status_ok)
         goto out;
 
-    puts(buf);
+    fputs(buf,stderr);

puts() and fputs() are not quite synonymous. puts() will unconditionally add an extra newline to stdout. It is unclear whether the string from yajl_gen_get_buf() comes with a trailing newline or not. If the output looks ok, it probably is fine.

~Andrew