On Mon, Nov 20, 2006 at 04:34:25PM -0500, Graham, Simon wrote:
> Signed-off by: Simon Graham <Simon.Graham@xxxxxxxxxxx>
>
> There is a somewhat trivial issue with XendCheckpoint.py right now in
> that it logs everything written to stderr by xc_save and xc_restore as
> errors whereas in fact the vast majority of this output is
> information/debug (and all actual errors are marked by the string ERROR:
> at the start of the message) -- this is confusing to folks looking at
> the logs and makes automated log analysis tricky.
>
> Fix is to scan for the ERROR: string and log anything without it using
> log.info instead.
This bit of XenD looks rather dubious to me. XenD spawns a background
thread, which in turn forks the xc_save or xc_restore program, reading
the stdout from this child process.
Aside from command line argument handling, the xc_save and xc_restore
programs each only make *one* single function call to xc_linux_save or
xc_linux_restore APIs in libxc.
But XenD already has libxc loaded & calls it directly for all other jobs
its needs to do, including actually createing the domain in the first
place. So why is it going to all the trouble of fork'ing a child process
rather than just calling xc_linux_save/restore APIs directly ? If it
did this, we wouldn't need this loop to read, grok & log STDOUT from the
child process at all - it would just end up in regular XenD logs.
And even more importantly, once we get the error reporting patches integrated
into libxc, having the xc_linux_save/restore calls made by XenD directly
would ensure we get reliable error handling for save/restore operations.
So, is there any good reason for xc_save & xc_restore to exist as separate
processes - it just seems like a huge complication to me, increasing
fragility of the system & reducing the quality of error reporting we can
get
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home