From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: Unable to create VM with nic device on Arndale Date: Fri, 17 Jan 2014 14:31:09 +0100 Message-ID: <52D9309D.1030808@citrix.com> References: <52B181EB.6080303@samsung.com> <21169.39199.902511.563980@mariner.uk.xensource.com> <52B1A1B9.70307@samsung.com> <1387373404.28680.19.camel@kazak.uk.xensource.com> <52B1B616.4010402@samsung.com> <1389951973.6697.47.camel@kazak.uk.xensource.com> <1389955476.6697.58.camel@kazak.uk.xensource.com> <1389956491.6697.64.camel@kazak.uk.xensource.com> <1389959942.6697.87.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1389959942.6697.87.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 , "Dennis Lan (dlan)" Cc: Eugene Fedotov , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 17/01/14 12:59, Ian Campbell wrote: > On Fri, 2014-01-17 at 19:43 +0800, Dennis Lan (dlan) wrote: >> On Fri, Jan 17, 2014 at 7:01 PM, Ian Campbell wrote: >> >> >>> vif-bridge and the common scripts which it includes would be a good >>> start. Just an echo at the top to confirm that the script is running >>> would be useful. >>> >>> I used to do "exec 1>/tmp/hotplug.log 2>&1" at the top to aid debugging >>> when these scripts were launched by udev, but now that libxl runs them >>> you may find that the debug from the script comes out on stdout/err of >>> the xl create command so perhaps that isn't needed any more. >>> >>>> headless here. >>> >>> That shouldn't matter, you are looking for output from userspace >>> scripts, not kernel or hypervisor logs. >>> >>> Ian. >>> >> >> Hi Ian >> I suspect for 4.4.0, the network devices even was not detected. >> this is output from 4.3.1, notes follow lines. >> >> libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug >> script: /etc/xen/scripts/vif-bridge online >> dlan: vif-bridge start >> dlan: vif-common start >> >> dlan: vif-bridge start -> output from vif-bridge script >> dlan: vif-common start -> output from vif-common.sh script > > So these are the 4.3 logs? Have you tried 4.4 and found that it doesn't > produce the same output? > > (please can you try and set the text type to "preformatted" for the logs > -- having them wrapped makes them very hard to read). > > The lack of > libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online > in your original logs is a bit concerning. > > Roger -- any ideas? My first guess would be that libxl__get_domid failed, however I'm not able to reproduce this. I'm attaching a patch to add an error message if libxl__get_domid fails, and also prevent the removal of xenstore entries so we can see what's going on. Dennis/Eugene, could you try the attached patch and send the output of xl -vvv create <...> and xenstore-ls -fp after the failed creation? --- diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index a604cd8..03f9fe9 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -1296,6 +1296,9 @@ static void domcreate_complete(libxl__egc *egc, rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref); if (rc) { + LOG(ERROR, "domain creation failed, not doing removal of xs entries"); + dcs->callback(egc, dcs, rc, -1); + return; if (dcs->guest_domid) { dcs->dds.ao = ao; dcs->dds.domid = dcs->guest_domid; diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index ba7d100..56d8162 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -965,7 +965,10 @@ static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev) * hotplug scripts */ rc = libxl__get_domid(gc, &domid); - if (rc) goto out; + if (rc) { + LOG(ERROR, "unable to get domain id, error: %d", rc); + goto out; + } if (aodev->dev->backend_domid != domid) { if (aodev->action != LIBXL__DEVICE_ACTION_REMOVE) goto out;