From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: broken live migration in xen 4.3 (release) Date: Tue, 18 Mar 2014 10:49:06 +0100 Message-ID: <53281692.7070100@citrix.com> References: <1395061109.18221.7.camel@kazak.uk.xensource.com> <1395135419.12847.4.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WPqdy-0000Mc-8f for xen-devel@lists.xenproject.org; Tue, 18 Mar 2014 09:49:25 +0000 In-Reply-To: <1395135419.12847.4.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Vasiliy Tolstov Cc: xen-devel@lists.xenproject.org, Ian Jackson List-Id: xen-devel@lists.xenproject.org On 18/03/14 10:36, Ian Campbell wrote: > On Tue, 2014-03-18 at 03:25 +0400, Vasiliy Tolstov wrote: >> I'm solve my issue. /etc/xen/scripts/vif-ospf (my own network script) >> have which ethtool not redirected to /dev/null. >> When domain started i don't have errors, but when migration appeared >> last message has been /sbin/ethtool. Thanks Ian Campbell and Ian >> Jackson! > > Great. > > Did you by any chance produce a debug patch to help you track this down > (e.g. to log the unexpected message)? If so then that might be something > which is useful to others diagnosing the same issue -- would you mind > submitting it? See http://wiki.xen.org/wiki/Submitting_Xen_Patches for > guidance. (Even if it is unsuitable for applying it would perhaps be > helpful to have in the list archives to point at) > > Roger, where should the hotplug scripts be logging to? Should we > consider slurping up stdout/stderr of the script to somewhere other than > xl's std*? IMHO I like hotplug messages to be printed on screen while using xl create/destroy... But for migration it should be redirected to /dev/null or some suitable logfile I guess. Or maybe a more canonical way to deal with this would be to always redirect the output of hotplug scripts to a temp file, and in case of not doing a migration print the contents of the file after executing the hotplug script. Roger.