similar to: Bug#655301: xcp-xapi fails to start

Package: xcp-xapi Version: 1.3-15 Severity: normal By default, xapi listens on the loopback interface. To make it available over the network, its inventory needs to be updated with the bridged interface details. For example, if xenbr0 is the bridged interface, it needs to be set it: lnx200-39:~# cat /etc/xcp/inventory BUILD_NUMBER='0' CURRENT_INTERFACES='xenbr0'

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-11 Severity: normal We need to have a separate user/group privilege for xapi and its dependent processes. At the moment, everything runs as root -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux

Package: xcp-xapi Version: 1.3-15 Severity: wishlist The current initscript has the possibility of slowing down the boot process by 50 seconds. If this is required, it probably should be backgrounded. # Wait for xapi to write its "init complete" cookie: after here it's safe to modify templates. wait_for_xapi() { MAX_RETRIES=50 RETRY=0 while [ ${RETRY} -lt ${MAX_RETRIES}

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 Severity: normal Tags: upstream Are there good reasons why xapi by default prefers to bidn to 80 and 443? This will lead to xapi installation/start failure on every server machine that might (and will probably) have apache installed. I know we can remove apache or change its port or change xapi's port (But I've had a hard time to easily find out where to specify the

Package: xen-utils-common Version: 4.1.2-3 Severity: important /etc/default/xen, which carries the TOOLSTACK setting, is not honored by xend init script. The xend initscript doesn't check for the value of TOOLSTACK. It just populates it in its initscript. lnx200-39:/etc/init.d# grep TOOLSTACK * xend:TOOLSTACK=$(/usr/lib/xen-common/bin/xen-toolstack 2>/dev/null) xend: if [ -z

I just noticed OpenXenCenter (aka OpenXenManager) that is an open source replacement for Citrix's XenCenter. This tool works with XenServer. But as per the blog entry: http://blog.xen.org/index.php/2010/02/09/xen-cloud-platform-installation/ it is also supposed to work with Xen Cloud Platform. XCP is licensed GPL2 and is a combination of multiple packages. Has the team looked at the

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}

http://bugs.freedesktop.org/show_bug.cgi?id=23832 Summary: extended display not working Product: xorg Version: 7.4 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

Package: xcp-networkd Version: 1.3.2-11 Severity: normal Given that openvswitch is one of the networking modes, it should be in the Recommends: than being in the Depends: -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64

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

Hi, Nice to receive your suggestions. Follwing the suggestions, the xapi service does work on a non XCP host and most of the xe interface of get information (such as "xe vm-list ")can work well. However, when I used the "xe sr-create" interface to create a SR, I got a error "The SR could not be connected because the driver was not recognised ". I noted that

Hi, Nice to receive your suggestions. Follwing the suggestions, the xapi service does work on a non XCP host and most of the xe interface of get information (such as "xe vm-list ")can work well. However, when I used the "xe sr-create" interface to create a SR, I got a error "The SR could not be connected because the driver was not recognised ". I noted that

Hi, I am a masters student at IIIT Hyderabad. I have applied for gsoc 2015, for xen in a box proposal. As a part of my proposal,I want to deliver xapi repo which can be used to build a custom installer ISO to install CentOS 6 + xen + xapi. Here is my full proposal http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/gautam_malu/5629499534213120 About building xapi packages for

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

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.

Package: xen-utils-common Version: 4.1.0~rc6-1 Severity: important Currently xend fails to create a fully virtualized vm because it has a different path hardcoded to it. Unable to complete install: 'POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: device model '/usr/lib64/xen/bin/qemu-dm' not found")' The correct path to use

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:

Hi there. I needed to recompile xapi to fix a bug that was resolved regarding vdi-create not setting the sharable flag. I used the sources provided in the source-1.iso from xen.org. Everything is good in this regard, and creating a vdi that has "sharable=true" is possible, but I had a problem that forced me to revert to the older copy of the xapi binary because my XCP box was now being