On Mon, Nov 20, 2006 at 09:56:00PM +0000, Daniel P. Berrange wrote:
> 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
It was done because, in the past, we didn't trust the stability of the
save and restore code, and didn't want it taking down the whole of Xend.
You could argue that that code is much more reliable now, and so we
don't need all this complexity. Then again, with HVM live migration
work upcoming, maybe we'll come appreciate the isolation again.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home