similar to: Bug#688216: Add documentation on how to change toolstack to README.Debian

tags 466683 +patch thanks commit 765ac4708e4dd8a6fea0028d631a7c3363b286b7 Author: Ian Campbell <ijc at hellion.org.uk> Date: Fri Aug 16 10:30:17 2013 +0100 * debian/changelog: Update * debian/templates/control.main.in: Update descriptions for some packages. diff --git a/xen/debian/changelog b/xen/debian/changelog index 6100e75..e5b25ef 100644 --- a/xen/debian/changelog +++

Processing commands for control at bugs.debian.org: > retitle 655301 xend shouldn't start if TOOLSTACK is not xm Bug #655301 [xcp-xapi] xcp-xapi fails to start Changed Bug title to 'xend shouldn't start if TOOLSTACK is not xm' from 'xcp-xapi fails to start' > reassign 655301 xen-utils-common Bug #655301 [xcp-xapi] xend shouldn't start if TOOLSTACK is not xm Bug

Package: xcp-xapi Version: 1.3.2-9 Severity: normal Hi guys, Just a couple of things I noticed running through /usr/share/doc/xcp-xapi/README.Debian.gz as referenced by http://wiki.debian.org/XCP In "4/ Configuring Xen and XCP": sed -i "s/TOOLSTACK=/TOOLSTACK=xapi/" /etc/default/xen should be sed -i "s/TOOLSTACK=.*/TOOLSTACK=xapi/" /etc/default/xen Otherwise

tags 407143 +patch thanks On Fri, 2013-08-16 at 14:42 +0100, Ian Campbell wrote: > tags 688308 +patch > thanks > > A lot of /docs/ is pretty low-level and not all that interesting to be > installed by the packages. However some of it is, and in particular some > is referenced from the manpages. I've cherry-picked the bits which I > think are most interesting in that

Hello, I installed the last version of Xen (xenserver-core-0.9.0-9.x86_64 from yum) and I'm trying to manage my VMs with virsh. The version that I installed is using the Xapi/xe toolstack. The problem I have is that I'm not seeing the VM that is started with "virsh -c xen:/// list --all". Here is what I have: root# xe vm-list uuid ( RO) :

tags 688308 +patch thanks A lot of /docs/ is pretty low-level and not all that interesting to be installed by the packages. However some of it is, and in particular some is referenced from the manpages. I've cherry-picked the bits which I think are most interesting in that context. Patch below. 8<--------------- commit 7f8ac283e684b7c713d52ed845cab0704a97abab Author: Ian Campbell <ijc

This should have gone here and not to #706233. Patch will obviously need rebasing by now... ----- Forwarded message from Ian Campbell <ijc at hellion.org.uk> ----- Date: Fri, 16 Aug 2013 14:56:49 +0100 From: Ian Campbell <ijc at hellion.org.uk> To: 706233 at bugs.debian.org Cc: control at bugs.debian.org Subject: move core dumps to /var/lib/xen/dump X-Spam-Status: No, score=-4.9

tags 706233 +patch thanks This is somewhat more FHS compliant IMHO. commit 7d171826bc97bf5f3f2019fc32c1ca85b49de7c9 Author: Ian Campbell <ijc at hellion.org.uk> Date: Fri Aug 16 14:54:42 2013 +0100 * debian/patches/tools-core-dump-dir.patch: Switch tools to dumping to /var/log/xen/dump by default. * debian/xen-utils-common.dirs: Ensure /var/lib/xen/dump is created *

Hopefully someone knows the answer to this, BUT has anyone successfully installed the XAPI Toolstack on a Debian Dom0 (such as Squeeze or Wheezy OR even latest Ubuntu is similar enough) WITH Xen 4.2-unstable compiled and running? AND if so, how to do that? Thank you.

Control: tag -1 +patch (experimenting with http://www.donarmstrong.com/posts/control_at_submit/ ...) Hi Thomas, I think it is as simple as the following, which works for me with xl and xm. Does it work as you expect/want with xe? Ian. >From 88f10bc8dbf96dd2c32f12259249f8be70fd01a4 Mon Sep 17 00:00:00 2001 From: Ian Campbell <ijc at hellion.org.uk> Date: Thu, 19 Jul 2012 16:19:09

Package: xcp-xapi Severity: important The README doc mentions: 4/ Configuring Xen and XCP -------------------------- 4.1/ Switch using xl instead of xm and xend to control Xen As of writing, you should do that: sed -i "s/TOOLSTACK=/TOOLSTACK=xl/" /etc/default/xen Where as the init script checks for: # Exit cleanly if TOOLSTACK != xapi if [ "${TOOLSTACK}" !=

There's no date defined yet, but Wheezy freeze will happen soon. How do we plan on concluding on this bug report? Recap for the actual bug I reported: If you want to start xapi, execute the following steps: 1) Start /etc/init.d/xend 2) Stop /etc/init.d/xend 3) Start /etc/init.d/xcp-xapi Step 1 is required because you need access to /proc/xen/ Step 2 is required because xapi cannot run

Package: xcp-xapi Version: 1.3.2-15 Severity: normal I am trying to pass an SRIOV virtual function in a virtual machine but the attempt fails with the following errors shown in the xcp-xapi.log [20130829T19:29:17.909Z|debug|sriov1|314 UNIX /var/lib/xcp/xapi|VM.start R:9e8e10bd31bb|pciops] PCI devices from other-config:pci to attach: 0/0000:04:00.1 [20130829T19:29:18.012Z|debug|sriov1|314 UNIX

Package: xcp-xapi Version: 1.3.2-8 Severity: important During startup /etc/init.d/xendomains script is called. That script is installed with xen-utils-common witch xcp-xapi is depends on. That script calls /usr/sbin/xen as xen list &> /dev/null This 'xen' seems to call xapi: xen list ^Z [1]+ Stopped xen list root at lab-xh3:~# ps f PID TTY STAT TIME

libxenapi-ocaml-dev_1.3.2-2_amd64.deb to main/x/xen-api/libxenapi-ocaml-dev_1.3.2-2_amd64.deb python-xenapi_1.3.2-2_all.deb to main/x/xen-api/python-xenapi_1.3.2-2_all.deb (new) xcp-networkd_1.3.2-2_amd64.deb extra admin daemon to manage network configuration for xcp-xapi The Xen Cloud Platform (XCP) is an open source enterprise-ready server virtualization and cloud computing platform, with

One of the cluster nodes (XS 5.6 SP2/not master) became unresponsive to XAPI calls being sent from a CloudStack management server. In the past, a simple xe-toolstack-restart would do the trick but the script timed out while restarting the XAPI daemon. I found the process and first tried to use a simple kill command but the process was in a "defunct" state. I tried a kill -9 but no joy.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2013-2072 / XSA-56 version 2 Buffer overflow in xencontrol Python bindings affecting xend UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The Python bindings for the xc_vcpu_setaffinity call do not properly check their inputs. Systems

Processing commands for control at bugs.debian.org: > forcemerge 688216 688227 Bug #688216 [xen-utils-4.2] xen-utils-4.2: xl does not work Bug #688227 [xen-utils-4.2] xen-utils-4.2: /etc/default/xen TOOLSTACK undocumented Severity set to 'normal' from 'important' Merged 688216 688227 > thanks Stopping processing here. Please contact me if you need assistance. -- 688216:

Guillaume Thouvenin <guillaume.thouvenin@polymtl.ca> a écrit : > "Daniel P. Berrange" <berrange@redhat.com> a écrit : >> If you have new enough libvirt and Xen >= 4.2 then libvirt will >> automatically >> use the libxl APIs instead of XenD. I have compiled a version 1.1.2 (with xapi and xl support) and installed it in /usr/local. I started the

Package: xcp-xapi Version: 1.3.2-9 Severity: normal Function wait_for_xapi in /etc/init.d/xcp-xapi does not work as intented. Symptoms: (on slave) /etc/init.d/xcp-xapi restart [....] Restarting The XenAPI server: xapiThe host toolstack is still initialising. Please wait. Cause: Line 'xe pif-scan host-uuid=${INSTALLATION_UUID}' called before xapi is fully synced with master.