similar to: xen-api: xcp-xapi.init conflicts with xend

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}" !=

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

On 10/26/2011 05:29 AM, Mike McClurg wrote: > Perhaps you could send us a private deb file to test? I'm worried that > this might not be the right version that we need. Can you point us at > the upstream code you used? I used what was in the Git at: http://github.com/jonludlam/blktap.git The clone was made about a month ago, and it would be hard for me to tell when exactly. Adding

Package: xcp-xapi Version: 1.3.2-8 Severity: important Tags: patch Found race condition (specific only to slave hosts): xcp-xapi can start earlier than xcp-networkd due lack of dependency in init.d script. Syptoms: After reboot slave's xcp does not work: xe (anything): The host failed to acquire an IP address on its management interface and therefore cannot contact the master. log:

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.

Package: xcp-xapi Version: 1.3.2-6 Severity: important Looks like on Wheezy, /etc/default/xen is not created by xen-utils-common. Since xcp-xapi depends on its existence and further declaration of the toolstack in it, it should take extra care to ensure that it is present. root at debian:~# aptitude install xcp-xapi The following NEW packages will be installed: blktap-dkms{a} blktap-utils{a}

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

Thanks Jon, it worked, I was able to build all the packages for xenserver on CentOS 6.6 final version. Here is the package list: https://gist.github.com/gautammaloo/7616cccbe8f5c85c196e I was wondering what packages would be necessary to use Xen with xapi, I already have xen with xl installed. Could we have a package like http://packages.ubuntu.com/precise/xcp-xe with which we can have

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

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

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) :

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.

hi all, i meet a big problem, when i finish install xcp-xapi on ubuntu 12.04, i set grub to go into xen 4.1 kernel when startup and set echo ''TOOLSTACK="xapi"'' > /etc/default/xen when i reboot and login to the system , i got a lot out of memory error and all process be killed, seem like kernel crash. can anyone help me about that ? thanks.

You''re right scout the last line. Out looks like xapi is waiting on tapdisk to plug a key into xenstore. Perhaps a udev rule problem? Perhaps someone who knows more about tapdisk than I well be able to diagnose this tomorrow. Mike Sent from Samsung tablet Sébastien RICCIO <sr@swisscenter.com> wrote: Of course, here it is attached. Last line seems interesting. However tapdisk2

Hi, I am a masters student at IIIT Hyderabad, India. I am writing a GOSC proposal for CentOS organization. It's about delivering a custom installer ISO which delivers Xen 4.4 stack on CentOS 6. full proposal: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/gautam_malu/5629499534213120 I want to port xapi on CentOS 6 as part of it. There has been some previous efforts to

-----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

Package: xcp-xapi Version: 1.3.2-6 Severity: normal After some time of rebooting and toolstack restart found very funny output in 'xe pif-lis': xe pif-list params=currently-attached,device device ( RO) : vif2.0 currently-attached ( RO): false device ( RO) : vif211.0 currently-attached ( RO): false device ( RO) : eth1

Package: xcp-xapi Version: 1.3.2-6 Severity: important Configuration: Two xcp-xapi hosts (default sid/xcp-xapi installation) in single pool. Network backend is bridge. After migration of 'idle' (doning nothing) virtual machine it stops to reply to ping for long time. AFAIK that caused by mac-learning table on upper level (hardware) switch, which route all frames to wrong port

Package: xcp-xapi Version: 1.3.2-9 Severity: grave Justification: renders package unusable I've following mostly the xcp-xapi/README.Debian instructions after installing it with apt-get -t wheezy network.conf is configured for bridge, xenbrN are functioning and shown with xe network-list A single SR is present, created with ext on a local LVM. For debugging purposes, all ISO and local ISO

Hi list, Dave Scott has been working on a prototype of XenServer's Xapi running on stock CentOS 6.4 x86_64, with libvirt and ceph integration. He plans to demo this at the CentOS dojo in Aldershot next week. We'll be publishing the RPMs for this in a public Yum repo, and we would really like for these RPMs to eventually live in the xen-c6 repo. I was wondering what are the steps for