From: Ian Campbell <ian.campbell@citrix.com>
To: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>, suse.dev@fea.st
Subject: [PATCH] tools/libxl: improve logging on domain create failure.
Date: Tue, 26 Jan 2016 14:38:46 +0000 [thread overview]
Message-ID: <1453819126-10218-1-git-send-email-ian.campbell@citrix.com> (raw)
A user reported[0] that xl create failed with just:
libxl: error: libxl_create.c:892:initiate_domain_create: Unable to set domain build info defaults
and some resulting fallout, but without indicating why it was unable
to set the defaults, even in verbose mode[1].
Go through libxl__domain_{create,build}_info_setdefault and ensure
that each error path logs something.
In most cases this involved simply adding a call to LOG.
In two cases this involved switching from strdup to
libxl__strdup(NOGC) and removing the existing error handling.
When switching from qemu-xen to qemu-xen-traditional (because the
former is not available) log at level INFO rather than VERBOSE, so
the message would normally be printed. Also tweak the language here.
I'm not sure all these messages are reachable (some might be shadowed
by previous error paths) but it seems better to err on the side of
caution.
[0] http://lists.xen.org/archives/html/xen-users/2016-01/msg00125.html
[1] http://lists.xen.org/archives/html/xen-users/2016-01/msg00129.html
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: suse.dev@fea.st
---
suse.dev, this might help diagnose the issue you are seeing.
Given the usability issue, I think this ought to be backported.
---
tools/libxl/libxl_create.c | 48 +++++++++++++++++++++++++++++-----------------
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e491d83..de5d27f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -30,8 +30,10 @@
int libxl__domain_create_info_setdefault(libxl__gc *gc,
libxl_domain_create_info *c_info)
{
- if (!c_info->type)
+ if (!c_info->type) {
+ LOG(ERROR, "domain type unspecified");
return ERROR_INVAL;
+ }
if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
libxl_defbool_setdefault(&c_info->hap, true);
@@ -66,8 +68,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
int i;
if (b_info->type != LIBXL_DOMAIN_TYPE_HVM &&
- b_info->type != LIBXL_DOMAIN_TYPE_PV)
+ b_info->type != LIBXL_DOMAIN_TYPE_PV) {
+ LOG(ERROR, "invalid domain type");
return ERROR_INVAL;
+ }
libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
@@ -97,8 +101,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
if (rc < 0) {
/* qemu-xen unavailable, use qemu-xen-traditional */
if (errno == ENOENT) {
- LOGE(VERBOSE, "qemu-xen is unavailable"
- ", use qemu-xen-traditional instead");
+ LOGE(INFO, "qemu-xen is unavailable"
+ ", using qemu-xen-traditional instead");
b_info->device_model_version =
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
} else {
@@ -121,18 +125,24 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
b_info->u.hvm.bios = LIBXL_BIOS_TYPE_SEABIOS; break;
case LIBXL_DEVICE_MODEL_VERSION_NONE:
break;
- default:return ERROR_INVAL;
+ default:
+ LOG(ERROR, "unknown device model version");
+ return ERROR_INVAL;
}
/* Enforce BIOS<->Device Model version relationship */
switch (b_info->device_model_version) {
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
- if (b_info->u.hvm.bios != LIBXL_BIOS_TYPE_ROMBIOS)
+ if (b_info->u.hvm.bios != LIBXL_BIOS_TYPE_ROMBIOS) {
+ LOG(ERROR, "qemu-xen-traditional requires bios=rombios.");
return ERROR_INVAL;
+ }
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
- if (b_info->u.hvm.bios == LIBXL_BIOS_TYPE_ROMBIOS)
+ if (b_info->u.hvm.bios == LIBXL_BIOS_TYPE_ROMBIOS) {
+ LOG(ERROR, "qemu-xen does not support bios=rombios.");
return ERROR_INVAL;
+ }
break;
case LIBXL_DEVICE_MODEL_VERSION_NONE:
break;
@@ -160,19 +170,25 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
if (!b_info->max_vcpus)
b_info->max_vcpus = 1;
if (!b_info->avail_vcpus.size) {
- if (libxl_cpu_bitmap_alloc(CTX, &b_info->avail_vcpus, 1))
+ if (libxl_cpu_bitmap_alloc(CTX, &b_info->avail_vcpus, 1)) {
+ LOG(ERROR, "unable to allocate avail_vcpus bitmap");
return ERROR_FAIL;
+ }
libxl_bitmap_set(&b_info->avail_vcpus, 0);
- } else if (b_info->avail_vcpus.size > HVM_MAX_VCPUS)
+ } else if (b_info->avail_vcpus.size > HVM_MAX_VCPUS) {
+ LOG(ERROR, "avail_vcpus bitmap contains too many VCPUS");
return ERROR_FAIL;
+ }
/* In libxl internals, we want to deal with vcpu_hard_affinity only! */
if (b_info->cpumap.size && !b_info->num_vcpu_hard_affinity) {
b_info->vcpu_hard_affinity = libxl__calloc(gc, b_info->max_vcpus,
sizeof(libxl_bitmap));
for (i = 0; i < b_info->max_vcpus; i++) {
- if (libxl_cpu_bitmap_alloc(CTX, &b_info->vcpu_hard_affinity[i], 0))
+ if (libxl_cpu_bitmap_alloc(CTX, &b_info->vcpu_hard_affinity[i], 0)) {
+ LOG(ERROR, "failed to allocate vcpu hard affinity bitmap");
return ERROR_FAIL;
+ }
libxl_bitmap_copy(CTX, &b_info->vcpu_hard_affinity[i],
&b_info->cpumap);
}
@@ -318,18 +334,14 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
return ERROR_INVAL;
}
- if (!b_info->u.hvm.boot) {
- b_info->u.hvm.boot = strdup("cda");
- if (!b_info->u.hvm.boot) return ERROR_NOMEM;
- }
+ if (!b_info->u.hvm.boot)
+ b_info->u.hvm.boot = libxl__strdup(NOGC, "cda");
libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
- if (!b_info->u.hvm.vnc.listen) {
- b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
- if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
- }
+ if (!b_info->u.hvm.vnc.listen)
+ b_info->u.hvm.vnc.listen = libxl__strdup(NOGC, "127.0.0.1");
}
libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);
--
2.1.4
next reply other threads:[~2016-01-26 14:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 14:38 Ian Campbell [this message]
2016-01-28 10:52 ` [PATCH] tools/libxl: improve logging on domain create failure Wei Liu
2016-02-03 11:50 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453819126-10218-1-git-send-email-ian.campbell@citrix.com \
--to=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=suse.dev@fea.st \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).