Bug#738322: RM: xen-api and friends -- ROM; non maintained upstream
Hi Thomas, No, I don't believe anything other than Xapi depended upon blktap, though it could theoretically be useful to anyone who wants VHD-backed disks. I no longer work for Citrix, though, so I'm not the best person to comment on this. Mike On Sat, Feb 8, 2014 at 11:18 PM, Thomas Goirand wrote: > Package: ftp.debian.org > Severity: normal > > > Hi, > > Writting this message saddens me, but no choice... > > Because upstream authors (eg: Citrix) have explained that they cannot > maintain the current version of XenAPI, or upgrade it to a newer version, > we have no choice but to remove completely XenAPI from both Unstable and > Testing. Quoting Euan Harris from Citrix (it's not needed for the FTP > masters to read, however it's useful to have this in a public bug for > future reference): > > > the next 5 years.Unfortunately the changes we had to make to the XCP > > packages to make them build on Debian made them effectively a fork of the > > XAPI Project as used in XenServer at that time, and it is increasingly > > difficult to backport changes from 'upstream' XAPI Project to XCP. > > > > I previously mentioned a project called 'xenserver-core' > > (https://github.com/xenserver/xenserver-core) which aimed to improve and > > standardize the build and packaging process for XenServer's components. > > As part of project we cleaned up many of the CentOS/RedHat-specific > > dependencies in the packages, and we are now pushing those changes back > > upstream to the main repositories including those of the XAPI Project > > (https://github.com/xapi-project). > > > > xenserver-core also had build scripts which let us build the packages > > on RedHat- and Debian-derived distributions. We plan to integrate this > > build code into our main build system, so we hope that we will not see a > > repeat of the divergence that occurred with the XCP packages as we will > > be building (internally) on Debian on a regular basis.We hope that > > this will mean that our trunk branch and future releases will be much > > easier for packagers to build in future than it has been in the past. > > > > In summary, the current XCP packages are not in a good enough condition > > to go into Ubuntu Trusty and the trunk XAPI Project is not yet at a point > > where a release can be made. Typically we do this when XenServer is > > released and the XAPI code has had significant testing and stabilization > > through XenServer's QA process. > > > > Regrettably, we agree that there is no alternative now but for the > > XCP packages to drop out of the Ubuntu Trusty. We would like to get > > packages in Debian testing again in time for the next release, but those > > should be based on releases from XAPI Project trunk rather than the XCP > > branches, which should be considered dead. We don't have the resources > or > > expertise to build the packages ourselves, but we are keen to work with > > you (or other Debian maintainers) to fix any Debian-specific problems > > which make our code difficult to package. As I've explained above, we > > are putting a lot of effort into making the XAPI Project code portable > > and less distribution specific, so we would hope that packaging it for > > Debian will now be much easier than it used to be. > > To give a shorter submary: XCP in it's current Debian form is dead, and > may be replaced by xenserver-core when upstream consider it in good enough > shape. It is my intention to work on that when it is available. But in > the mean while, I hereby request the removal of the below packages from > both Sid and Testing: > > - guest-templates > - xcp-eliloader > - xcp-storage-managers > - xcp-vncterm > - xen-api > - xen-api-libs > > I am currently unsure if we should keep: > - blktap > - blktap-dkms > > I would appreciate comments from knowledgeable people like one of the > 2 Ian (eg: Campbell, Jackson), or Mike about this. I currently believe > that blktap isn't needed anymore outside of XCP, so unless they oppose > to it, we can delete these packages (if we later need them, I can anyway > upload again using what we have stored in the Git of Alioth). > > Thanks, > > Thomas Goirand (zigo) >
Bug#731166: [Pkg-xen-devel] Bug#731166: Error: Syntax error: 'end' expected
What OCaml compiler version is in oldstable?
Bug#707463: xcp-storage-managers: FTBFS: xslib_wrap.c:125:20: fatal error: Python.h: No such file or directory
On Thu, May 16, 2013 at 2:24 PM, Matthias Klose wrote: > Control: tags -1 + patch > > your patch looks fine to me, could you upload that fix, or please let me > know if > I can help with a NMU. > > Matthias > > Hi Matthias, I'd be great if you could help with an NMU. I'm not experienced with doing uploads. Thanks, Mike
Bug#707463: [Pkg-xen-devel] Bug#707463: Bug#707463: xcp-storage-managers: FTBFS: xslib_wrap.c:125:20: fatal error: Python.h: No such file or directory
Hi Thomas, Would you please review and push this patch for me? Mike On Sat, May 11, 2013 at 2:15 PM, Mike McClurg wrote: > > cc -O2 -I/usr/include/python2.6 -I/usr/include -fPIC -c -o > xslib_wrap.o xslib_wrap.c > > Looks like the Makefile is specifying Python 2.6 instead of Python 2.7. I > should have this fixed soon. > > Mike > > > ___ > Pkg-xen-devel mailing list > pkg-xen-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel > 0001-snapwatchd-includes-Python-2.7-headers-Closes-707463.patch Description: Binary data
Bug#707463: [Pkg-xen-devel] Bug#707463: xcp-storage-managers: FTBFS: xslib_wrap.c:125:20: fatal error: Python.h: No such file or directory
> cc -O2 -I/usr/include/python2.6 -I/usr/include -fPIC -c -o xslib_wrap.o xslib_wrap.c Looks like the Makefile is specifying Python 2.6 instead of Python 2.7. I should have this fixed soon. Mike
Bug#695221: [Pkg-xen-devel] Bug#695221: confirmed bug, serious
Hi all, Sorry for top posting. I spoke with Rob, the author of xcp-networkd, who thinks that he's fixed this bug in a later upstream release. We'll take a look at the repo tomorrow and see if we can find the commit that fixes this issue. Mike On Tue, Feb 12, 2013 at 3:22 AM, Thomas Goirand wrote: > On 02/11/2013 04:22 PM, Daniel Pocock wrote: > > Having it marked RC may allow a patch into wheezy. > > Marking it RC is only delaying the release, that's it. I have already > fixed multiple bugs which were not marked as RC, and the release team > accepted the changes. Even after Wheezy is released, it is possible to > fix problems in the stable distribution. > > > Maybe even a small patch: > > A small patch is what we should all aim at. I'm sure the problem isn't > so complicated, and that we can fix it. > > Of course, it would help if Mike and Jon were a bit more cooperative and > were trying to fix the issue, but it seems they are quite busy these > days (or maybe in holidays?). > > > > > - updating the README > > > > - changing pif-reconfigure-ip to give an error if the user tries a > > netmask that is not supported, e.g. > > > > "XCP only works on a Class C subnet with a netmask 255.255.255.0. Your > > changes have not been applied. > > See bug 695221 or the README file." > > Yeah, I think that is indeed a good idea to write this! > > > These things would be small fixes but would make the user's first > > experience of XCP less frustrating > > > > The last thing you want is for people to get frustrated and start > > thinking that they should try the Ubuntu version or the ISO installer: > > http://www.xen.org/download/xcp/index_1.6.0.html#install > > Well, yes, I would like to have more Debian users, and that people use > less XCP from the ISO installer (eg: CentOS based). However, the Ubuntu > package of XCP is synced from Debian, so these are the exact same > package (with only a possible delay in having the Ubuntu package). > Nobody in Ubuntu works on the XCP packaging, the work is only been done > by myself in Debian. > > >> Ultimately, this is the job of the maintainer of a given package to > >> decide the seriousness of a bug. To me, setting it to either normal or > >> important is exactly the same (eg: it is on my radar, and I really want > >> to have it fix), and discussing the seriousness doesn't help. Discussing > >> ways to fix it does. > > > > It's not quite the same, because the release team wouldn't accept a > > patch/unblock request for a normal issue > > This statement is completely wrong. The criteria for the release team to > accept changes is not the severity of a bug only. If we find a way to > fix this problem, I'm quite sure that the release team will accept the > patch, regardless of the severity set in the BTS. > > > I'm hoping that the fix for this might be quite trivial and therefore > > acceptable to the release team. > > Yeah, that's more in line! If the fix is small, and even trivial, and > easy to review for them (which is quite likely to be the case, > considering that just fixing the db with an editor fixed it for you), > then they will accept it. > > I'm also quite sure that they would accept any documentation change at > this point of the release. > > Cheers, > > Thomas >
Bug#687319: xcp-storage-managers: CDROM VDIs don't hotplug in guests because ISO SRs are misconfigured
Package: xcp-storage-managers Version: 0.1.1-2ubuntu1 Severity: normal This bug prevents CDROM VDIs from being hotplugged into guest VMs. The issue is that the NFS ISO SR configures the ISO VDIs to be 'file' types, which it should configure them to by 'phy' types. This breaks on Debian's Xen because the Debian hotplug scripts are more robuse than the ones on XenServer, and fail because the VDI type is set improperly. A debdiff is attached. -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise'), (100, 'precise-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-30-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xcp-storage-managers depends on: ii blktap-utils2.0.90-1 ii libc6 2.15-0ubuntu10 ii libxenstore3.0 4.1.2-2ubuntu2.2 ii python 2.7.3-0ubuntu2 ii python2.7 2.7.3-0ubuntu3.1 ii uuid-runtime2.20.1-1ubuntu3 Versions of packages xcp-storage-managers recommends: ii lvm22.02.66-4ubuntu7.1 ii nfs-common 1:1.2.5-3ubuntu3 xcp-storage-managers suggests no packages. -- no debconf information diff -Nru xcp-storage-managers-0.1.1/debian/changelog xcp-storage-managers-0.1.1/debian/changelog --- xcp-storage-managers-0.1.1/debian/changelog 2011-12-17 16:47:38.0 + +++ xcp-storage-managers-0.1.1/debian/changelog 2012-09-04 11:15:29.0 +0100 @@ -1,3 +1,9 @@ +xcp-storage-managers (0.1.1-3) unstable; urgency=low + + * Fix CDROM guest hotplug bug (LP: #1045739) + + -- Mike McClurg Tue, 04 Sep 2012 11:03:11 +0100 + xcp-storage-managers (0.1.1-2) unstable; urgency=low * New FHS compliant layout diff -Nru xcp-storage-managers-0.1.1/debian/patches/0002-lvm2-path.patch xcp-storage-managers-0.1.1/debian/patches/0002-lvm2-path.patch --- xcp-storage-managers-0.1.1/debian/patches/0002-lvm2-path.patch 2011-12-17 16:47:38.0 + +++ xcp-storage-managers-0.1.1/debian/patches/0002-lvm2-path.patch 2012-09-04 11:15:29.0 +0100 @@ -4,7 +4,7 @@ --- drivers/lvutil.py |4 ++-- - 1 files changed, 2 insertions(+), 2 deletions(-) + 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/lvutil.py b/drivers/lvutil.py index e9bf30a..a6c9914 100755 diff -Nru xcp-storage-managers-0.1.1/debian/patches/0003-fpic-on-xslib.patch xcp-storage-managers-0.1.1/debian/patches/0003-fpic-on-xslib.patch --- xcp-storage-managers-0.1.1/debian/patches/0003-fpic-on-xslib.patch 2011-12-17 16:47:38.0 + +++ xcp-storage-managers-0.1.1/debian/patches/0003-fpic-on-xslib.patch 2012-09-04 11:15:29.0 +0100 @@ -4,7 +4,7 @@ --- snapwatchd/Makefile |2 +- - 1 files changed, 1 insertions(+), 1 deletions(-) + 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/snapwatchd/Makefile b/snapwatchd/Makefile index 98cb1a9..addcbfb 100644 diff -Nru xcp-storage-managers-0.1.1/debian/patches/0004-remove-xencert.patch xcp-storage-managers-0.1.1/debian/patches/0004-remove-xencert.patch --- xcp-storage-managers-0.1.1/debian/patches/0004-remove-xencert.patch 2011-12-17 16:47:38.0 + +++ xcp-storage-managers-0.1.1/debian/patches/0004-remove-xencert.patch 2012-09-04 11:15:29.0 +0100 @@ -4,7 +4,7 @@ --- Makefile |1 - - 1 files changed, 0 insertions(+), 1 deletions(-) + 1 file changed, 1 deletion(-) diff --git a/Makefile b/Makefile index a42b056..a1ff8c5 100644 diff -Nru xcp-storage-managers-0.1.1/debian/patches/0005-vhd-util-path.patch xcp-storage-managers-0.1.1/debian/patches/0005-vhd-util-path.patch --- xcp-storage-managers-0.1.1/debian/patches/0005-vhd-util-path.patch 2011-12-17 16:47:38.0 + +++ xcp-storage-managers-0.1.1/debian/patches/0005-vhd-util-path.patch 2012-09-04 11:15:29.0 +0100 @@ -4,7 +4,7 @@ --- drivers/vhdutil.py |4 ++-- - 1 files changed, 2 insertions(+), 2 deletions(-) + 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/vhdutil.py b/drivers/vhdutil.py index 10b6994..6ddcd32 100644 diff -Nru xcp-storage-managers-0.1.1/debian/patches/0006-fix-local-device-change.patch xcp-storage-managers-0.1.1/debian/patches/0006-fix-local-device-change.patch --- xcp-storage-managers-0.1.1/debian/patches/0006-fix-local-device-change.patch 2011-12-17 16:47:38.0 + +++ xcp-storage-managers-0.1.1/debian/patches/0006-fix-local-device-change.patch 2012-09-04 11:15:29.0 +0100 @@ -6,7 +6,7 @@ # Parent 48aa86a502ee5df1519d3ea42528c77d8fcf9ff6 --- scripts/local-device-change |2 +- - 1 files changed, 1 insertions(+), 1 deletions(-) + 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/local-device-change b/scripts/local-device-change index 57fec20..2929bf1 100755 diff -Nru x
Bug#686778: [Pkg-xen-devel] Bug#686778: xcp-xapi: what user should xapi run as
On Wed, Sep 5, 2012 at 6:32 PM, Ritesh Raj Sarraf wrote: > 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 Unfortunately, with the way xapi is currently architected, we can't run it as a non-privileged user. Xapi itself makes calls to xenstore and to the hypervisor in too many places to split those bits out. In upstream xapi, we're working on splitting xapi into a few different daemons. When we finish this, we can package it for Debian such that only the daemon that makes xenstore calls and hypercalls is run as root. Because I think that it is impossible to patch 1.3.2 such that it can be run by a non-root user, I think that we should mark this bug as invalid. Do you agree? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680528: xen-utils-common: Please disable xendomains auto-start
On Thu, Jul 19, 2012 at 4:48 PM, Ian Campbell wrote: > On Thu, 2012-07-19 at 23:43 +0800, Thomas Goirand wrote: >> Hi Ian, >> >> Indeed, that seems ok to me. The only thing we needed was to not do >> anything with xm/xl if xapi is selected, and this does the job. > > Thanks. >> >> Now, one thing I'm not sure, is how XAPI should be recovering from >> an unexpected reboot (which is why I'm CC-ing Mike and Jon). I haven't >> seen any mechanism so that VMs managed by XCP are started/stopped >> at [re]boot time. Do you have any idea how that works? > > AFAIK scripts/init.d-xapi-domains in the xapi codebase does this using > whichever helper it calls. > > Ian. Yep, that's the one. We should have installed this with xcp-xapi. We'll need to patch that script to not call xapi-autostart-vms (which is being depricated upstream), and also make sure that we're touching a lock file in the appropriate /var/ directory. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680102: More fixes for xen-api in Wheezy
On Sat, Jul 7, 2012 at 11:15 PM, George Shuklin wrote: > On 08.07.2012 01:57, Mike McClurg wrote: >> We could change that to "/var/lib/xcp/firstboot.d". I'd like to know >> whether creating the /etc/firstboot.d directory will solve the problem >> though, before we make that change. >> >> Mike > > ok, here. > > note that previous attempt kick away host from pool, but without proper > local initialization. Here logs of second attempt (with > /etc/firstboot.d/data manually created directory): Okay, I've got a branch on my github for this. I've removed the call to xen-cmdline, and I've changed the firstboot directory to /var/lib/xcp/firstboot.d/. Thomas, I'm not sure what the best way is to make sure that this directory is properly created at xapi install time, so I've left that bit to you. https://github.com/mcclurmc/xen-api/tree/debian-sid-680102 Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680102: More fixes for xen-api in Wheezy
On Sat, Jul 7, 2012 at 11:01 PM, George Shuklin
wrote:
> Here results:
> # mkdir /etc/firstboot.d/
> # mkdir /etc/firstboot.d/data
> # xe pool-eject host-uuid=a6806a39-442d-f17d-b7a0-59161d18f562
>
> WARNING: Ejecting a host from the pool will reinitialise that host's local
> SRs.
> WARNING: Any data contained with the local SRs will be lost.
> Type 'yes' to continue
> yes
> The server failed to handle your request, due to an internal error. The
> given message may give details useful for debugging the problem.
> message: Failure("Error while calling xen-cmdline script")
>
>
> log snippet:
>
> [20120707T21:55:24.695Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject
> R:a16c35a5d1d4|xapi] Raised at forkhelpers.ml:181.30-76 ->
> pervasiveext.ml:22.2-9
> [20120707T21:55:24.695Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject
> R:a16c35a5d1d4|backtrace] Raised at pervasives.ml:22.22-33 ->
> list.ml:57.20-23 -> xapi_pool.ml:830.9-125 -> rbac.ml:229.16-23
> [20120707T21:55:24.697Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject
> R:a16c35a5d1d4|backtrace] Raised at rbac.ml:238.10-15 ->
> server_helpers.ml:72.10-22
> [20120707T21:55:24.697Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject
> R:a16c35a5d1d4|dispatcher] Server_helpers.exec exception_handler: Got
> exception INTERNAL_ERROR: [ Failure("Error while calling xen-cmdline
> script")
>
Thanks for testing this, George. Can you attach a copy of the logs
from the point that you issued the pool-eject command, up to this
line? I need a little more context.
>
> My opinion about 'eject' on debian:
> 1) Clear running VM's
> 2) Unplug all VBD
> 3) Unplug all PIF's but management
> 4) Wipe /var/lib/xcp/state.db
> 5) Wipe /var/lib/xcp/local.db
> 6) Keep only management interface data in /var/xcp/network.db
> 7) restart all xcp services.
>
> During playing with bug lack of '-onsystemboot' flag for xcp I've done that
> operation many times, seems it working without specific problems.
>
> It even works fine without host reboot.
I'll see if I can track down exactly what's happening on pool-eject,
and cut it down to the minimum necessary. Thanks again,
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680102: More fixes for xen-api in Wheezy
On Sat, Jul 7, 2012 at 10:40 PM, Thomas Goirand wrote: > On 07/08/2012 04:22 AM, Mike McClurg wrote: >> So 680102 is due to there not being an /etc/firstboot.d/ directory (as >> the ticket explains). I think we can fix this issue simply by >> mkdir'ing the directory /etc/firstboot.d/data at some point in xapi's >> installation. This would allow the pool-eject to proceed, but I think >> that there might be problems when the host reboots: since none of the >> firstboot scripts will be called, the host might not reinitialise >> properly. > > Well, writing in /etc dynamically is *forbidden* by the Debian policy. > The /etc folder is for configuration, not something else! If you were > using /var/lib/xcp-xapi, ok, but not /etc. > > Could you think about a better way to fix? Sure, we can change what xapi thinks is the firstboot directory. See ocaml/xapi/xapi_globs.ml:593 : let first_boot_dir = "/etc/firstboot.d/" We could change that to "/var/lib/xcp/firstboot.d". I'd like to know whether creating the /etc/firstboot.d directory will solve the problem though, before we make that change. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680102: More fixes for xen-api in Wheezy
(CC'ing George Shulkin, and the #680102 bug list) On Sat, Jul 7, 2012 at 4:37 PM, Thomas Goirand wrote: > Hi Mike and Jon, > > It would be really nice if you could have a look at these 3 pending > issues in the Debian bug tracker: > > #675052: xe vm-memory-target-set does not write target to xenstore > #678723: vif-interfaces added to database as PIF's > #680102: xcp fails eject host from pool (no /etc/firstboot.d found) > > It be great to have it fix asap, before the deep freeze of Wheezy. > > I've been able to fix others already. Other than that, only #680102 is a > concern. So 680102 is due to there not being an /etc/firstboot.d/ directory (as the ticket explains). I think we can fix this issue simply by mkdir'ing the directory /etc/firstboot.d/data at some point in xapi's installation. This would allow the pool-eject to proceed, but I think that there might be problems when the host reboots: since none of the firstboot scripts will be called, the host might not reinitialise properly. I think at this point that's all we can hope for. George, can you test that creating the /etc/firstboot.d/data directory gets you past the current exception your having? If this works good enough, let's make this the fix for now. Jon, do you have any other thoughts on this bug? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678923: [Pkg-xen-devel] Bug#678923: Acknowledgement (xcp-xapi: host-disable and host-reboot make host disable forever)
See branch debian-sid-678923 on my github account. https://github.com/mcclurmc/xen-api/tree/debian-sid-678923 Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674161: [Pkg-xen-devel] Bug#674161: Fix for #674161
On Thu, Jul 5, 2012 at 5:29 PM, Mike McClurg wrote: > On Sat, Jun 30, 2012 at 7:18 AM, Thomas Goirand wrote: >> Hi Mike and Dave, >> >> Could you please produce a patch so that we can fix #674161? I believe I >> should be able to get a freeze exception, but please do not wait too >> long until fixing. >> >> Also, please pull the debian-sid branch from Alioth, which has all the >> fixes I could find in the BTS. > > I've pushed a branch called debian-sid-674161 to my github account > with an untested fix for this issue. Could someone please pull and > test this for me? D'oh! I committed this fix to the upstream code, and not to a debian patch. Don't have time to fix the patch right now. It should still be testable, though. > Mike > > https://github.com/mcclurmc/xen-api/tree/debian-sid-674161 > > > > ___ > Pkg-xen-devel mailing list > pkg-xen-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678923: [Pkg-xen-devel] Bug#678923: Acknowledgement (xcp-xapi: host-disable and host-reboot make host disable forever)
On Thu, Jul 5, 2012 at 3:21 AM, George Shuklin wrote: > I've done some additional research on that bug. > > Brief bug description: > xe host-disable; xe host-reboot make host disabled endlessly after reboot > without chances to be enabled: > > > xe host-enable uuid= > The specified host is disabled and cannot be re-enabled until after it > has rebooted > > What I found: > > 1) That settings (host_disabled_until_reboot) is stored in > /var/lib/xcp/local.db. > Stopping xcp-xapi, removing that file and starting xcp-xapi back works . But > ugly hack. > 2) That attribute is written during reboot, initiated by xe host-reboot. > > Question is: what change that value in XCP? xapi or some other startup > script? Okay, I think that the problem is that we forgot to call xapi with the -onsystemboot flag in the xcp-xapi.init script. Here is an untested patch that you should be able to manually apply (as in edit the init file by hand) to test if this fixes the issue. I'll push a proper patch to my github soon. Mike diff --git a/debian/xcp-xapi.init b/debian/xcp-xapi.init index 055e17b..b3c5959 100755 --- a/debian/xcp-xapi.init +++ b/debian/xcp-xapi.init @@ -23,7 +23,7 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="The XenAPI server" NAME=xapi DAEMON=/usr/sbin/$NAME -DAEMON_ARGS="-daemon -writereadyfile $XAPI_STARTUP_COOKIE -writeinitcomplete $XAPI_INIT_COMPLETE_COOKIE" +DAEMON_ARGS="-daemon -writereadyfile $XAPI_STARTUP_COOKIE -writeinitcomplete $XAPI_INIT_COMPLETE_COOKIE -onsystemboot" PIDFILE=/var/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME TEMPLATES_MD5_STAMP=/var/lib/xcp/templates.md5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674161: Fix for #674161
On Sat, Jun 30, 2012 at 7:18 AM, Thomas Goirand wrote: > Hi Mike and Dave, > > Could you please produce a patch so that we can fix #674161? I believe I > should be able to get a freeze exception, but please do not wait too > long until fixing. > > Also, please pull the debian-sid branch from Alioth, which has all the > fixes I could find in the BTS. I've pushed a branch called debian-sid-674161 to my github account with an untested fix for this issue. Could someone please pull and test this for me? Mike https://github.com/mcclurmc/xen-api/tree/debian-sid-674161 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677395: [Xen-API] Bug#677395: xcp-xapi: xe pif-configure-ip does not remove old ip from interface
On 14/06/12 11:27, Rob Hoes wrote: > Hi George, > > Thanks for the report. > > You're right, it is indeed a bug. I fixed this a while ago in the master > branch on Github > (https://github.com/xen-org/xen-api/commit/731a05714e71ace0c9dfa7c0860db758071b740e), > but I think the fix did not make it to the debian repo yet. > > Mike says that he should be able to add it in. > > Cheers, > Rob Thanks Rob and George. I've added this patch to my debian-sid-work branch on my Github. https://github.com/mcclurmc/xen-api/tree/debian-sid-work Mike > > >> -Original Message- >> From: xen-api-boun...@lists.xen.org [mailto:xen-api- >> boun...@lists.xen.org] On Behalf Of George Shuklin >> Sent: 13 June 2012 16:08 >> To: Debian Bug Tracking System >> Subject: [Xen-API] Bug#677395: xcp-xapi: xe pif-configure-ip does not >> remove old ip from interface >> >> Package: xcp-xapi >> Version: 1.3.2-6 >> Severity: minor >> Tags: upstream >> >> If xe pif-configure-ip called twice with different IP, it did not >> remove old IP from interface (but didn't store both addresses in >> database). >> >> (Checked for management interface) >> >> Steps to reproduce: >> xe pif-reconfigure-ip uuid=... ip=IP1 >> xe pif-reconfigure-ip uuid=(same) ip=IP2 ... >> >> 'ip addr show' shows both addresses, and after reboot only IP2 is used. >> >> -- System Information: >> Debian Release: wheezy/sid >> APT prefers unstable >> APT policy: (500, 'unstable') >> Architecture: i386 (i686) >> >> Kernel: Linux 3.2.0-2-686-pae (SMP w/8 CPU cores) >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> >> Versions of packages xcp-xapi depends on: >> ii hwdata 0.233-1 >> ii libc6 2.13-33 >> ii libpam0g 1.1.3-7.1 >> ii libuuid1 2.20.1-5 >> ii libvhd02.0.90-1 >> ii libxen-4.1 4.1.2-6 >> ii libxenstore3.0 4.1.2-6 >> ii lsb-base 4.1+Debian7 >> ii pciutils 1:3.1.9-3 >> ii python 2.7.3~rc2-1 >> ii python-xenapi 1.3.2-6 >> ii stunnel4 [stunnel] 3:4.53-1 >> ii xcp-eliloader 0.1-4 >> ii xcp-fe 0.5.2-3+b1 >> ii xcp-networkd 1.3.2-6 >> ii xcp-squeezed 1.3.2-6 >> ii xcp-storage-managers 0.1.1-2 >> ii xcp-v6d1.3.2-6 >> ii xcp-xe 1.3.2-6 >> ii xen-hypervisor-4.1-amd64 [xen-hypervisor-4.1] 4.1.2-6 >> ii xen-utils-4.1 4.1.2-6 >> ii zlib1g 1:1.2.7.dfsg-11 >> >> Versions of packages xcp-xapi recommends: >> ii cifs-utils 2:5.5-1 >> ii xcp-guest-templates 0.1-3 >> ii xcp-vncterm 0.1-2 >> >> xcp-xapi suggests no packages. >> >> -- no debconf information >> >> >> >> ___ >> Xen-api mailing list >> xen-...@lists.xen.org >> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api > > ___ > Xen-api mailing list > xen-...@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675055: [Xen-API] Bug#675055: xcp-xapi: xe-edit-bootloader does not compatible with new /dev/sm
On 29/05/12 16:22, George Shuklin wrote: Package: xcp-xapi Version: 1.3.2-6 Severity: normal Tags: upstream /usr/lib/xcp/bin/xe-edit-bootloader failing with following message: /usr/lib/xcp/bin/xe-edit-bootloader -u 19f66083-e776-70d1-1808-3712688ad138 Creating dom0 VBD: 0fdb952e-92ff-4b53-dd49-8d54b2268787 Plugging VBD: Waiting for /dev/sm/backend/4c15ea03-5d70-938e-8265-d5424c0fda5e/963afb9a-9ceb-410f-8554-8be9fb70e7e0: . done Mounting filesystem: failed Partitions in the VDI are: brw--- 1 root root 252, 0 May 29 19:13 /dev/sm/backend/4c15ea03-5d70-938e-8265-d5424c0fda5e/963afb9a-9ceb-410f-8554-8be9fb70e7e0 You can use the -p option to specify a partition number to mount. Unplugging VBD: . done root@lab-xh3:~# /usr/lib/xcp/bin/xe-edit-bootloader -u 19f66083-e776-70d1-1808-3712688ad138 -p 1 Creating dom0 VBD: 445a1179-a947-b884-8cbe-06ea1515ee38 Plugging VBD: Waiting for /dev/sm/backend/4c15ea03-5d70-938e-8265-d5424c0fda5e/963afb9a-9ceb-410f-8554-8be9fb70e7e01: .Device /dev/sm/backend/4c15ea03-5d70-938e-8265-d5424c0fda5e/963afb9a-9ceb-410f-8554-8be9fb70e7e01 not found. Reason is that older model creates /dev/xvd* devices (see message history for bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674088 ) and xe-edit-bootloader just add partition number to device (/dev/xvdb -> /dev/xvdb1). With new sm model this is not true: script must call kpartx to probe partition table of attached VDI. Thanks for reporting this (and everything else ;) ). I'll file a bug with upstream xapi. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674161: [Pkg-xen-devel] Bug#674161: Acknowledgement (xcp-xapi: 'the device disappeared from xenstore' message during vbd-plug (vm-start))
On Wed, May 23, 2012 at 4:40 PM, George Shuklin wrote: > Found same problem with vif: > > xe vif-plug uuid=08e34a92-a973-e61d-1d41-2165a3d51073 > The server failed to handle your request, due to an internal error. The > given message may give details useful for debugging the problem. > message: the device disappeared from xenstore (frontend (domid=5 | kind=vif > | devid=0); backend (domid=0 | kind=vif | devid=0)) This should be a separate bug report, since there are different hotplug scripts for vifs and vbds. Can you file a new report, and make sure to include 1) the network backend, and 2) whether this is an HVM or PV guest? Also, check xcp-xapi.log to see if there are any lines that look like "waiting for xenstore", or something similar. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674161: [Pkg-xen-devel] Bug#674161: [Xen-API] Bug#674161: xcp-xapi: 'the device disappeared from xenstore' message during vbd-plug (vm-start)
On Wed, May 23, 2012 at 7:10 PM, George Shuklin wrote: > Some more data: > > Done clean reinstall (now with i386 in dom0), got exactly same error. What SR type are you using? If you are using something other than the FileSr, can you also attach SMlog from the relevant time period? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674161: [Pkg-xen-devel] Bug#674161: xcp-xapi: 'the device disappeared from xenstore' message during vbd-plug (vm-start)
Hi George, thanks for testing XCP on Debian! On Wed, May 23, 2012 at 3:07 PM, George Shuklin wrote: > Package: xcp-xapi > Version: 1.3.2-6 > Severity: normal > Tags: upstream > > vbd plug to PV domain cause following error: > > The server failed to handle your request, due to an internal error. The > given message may give details useful for debugging the problem. > message: the device disappeared from xenstore (frontend (domid=4 | kind=vbd | > devid=51760); backend (domid=0 | kind=vbd | devid=51760)) > # xe sr-create type=file name-label=fileSR device-config:location=/mnt > 319f3eaa-d1ba-a81d-acb3-493ecbdaab17 Here's the problem. The SR type "file" doesn't work the way you'd want it to. It's actually the base class for the ext and NFS backends, and isn't meant to be accessed directly. This class doesn't actually have the create methods required to actually create the appropriate directories necessary for a file-based SR. Could you please try to reproduce this bug with a different backend? NFS would probably be easiest. If the VBD plug happens on a different SR type, then I'll consider this a bug. Mike PS: As an aside, it should be possible to manually create an SR of this type yourself (or so the storage team leads me to believe). If you create a fresh uuid using uuidgen, you can then create a directory called /var/run/sm/, and then call 'xe sr-introduce type=file uuid= name-label=name'. I haven't tried this yet, but I'm about to. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674137: [Pkg-xen-devel] Bug#674137: xcp-xapi: default ports in xapi
On Wed, May 23, 2012 at 1:12 PM, Ritesh Raj Sarraf wrote: > On Wednesday 23 May 2012 05:01 PM, Marco d'Itri wrote: >> On May 23, Ritesh Raj Sarraf wrote: >> >>> > I am not sure of what the process is to get a port registered, but maybe >>> > Marco (CCed, the maintainer for netbase) can help. >> /etc/services is not really a good way to configure which port >> a service should bind to. > > Can you please elaborate more? > > XCP currently, be default, binds to 80 and 443. These are ports reserved > for http. > While I take your point that xapi is not a full-blown web server, it does in fact provide HTTP -- try pointing your browser at it. You can put HTML files in /var/www/html and xapi will serve them for you. So it's not wrong that xapi defaults to using ports 80 and 443, it's just a problem that it's not configurable. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674132: [Pkg-xen-devel] Bug#674132: xcp-xapi: backend check error
On Wed, May 23, 2012 at 11:56 AM, Ritesh Raj Sarraf wrote: > On Wednesday 23 May 2012 03:33 PM, Mike McClurg wrote: >> Should this really be an error? It's likely that for Xen 4.1, someone >> might have three toolstacks installed at the same time: xm, xl, and >> xapi. It seems that they should have the option to switch between the >> three without causing an error in the init scripts of the other two. >> >> In this case, do we really want to return an error here? > > In the README doc shipped by the package xcp-xapi, it should recommend > to use xapi as the TOOLSTACK. Yes, I gree that the README should tell the user to set TOOLSTACK=xapi if he or she wants to enable xapi. > If you are saying that xapi can support all the interfaces, then all of > them should be briefly touched upon. No, xapi cannot cope with xend running at the same time. It can cope with xl being used, as long as xl is not used to change the state of VMs which xapi is managing. What I am saying is that someone might want to switch to using xl instead of xapi. Making the change you suggested xcp-xapi.init would then mean that setting TOOLSTACK=xl would cause an error, when in fact it is a perfectly valid thing to do. > At this moment, following the README, it just fails. Agreed, let's make sure to add the TOOLSTACK=xapi setting to the README before Wheezy. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674137: [Pkg-xen-devel] Bug#674137: xcp-xapi: default ports in xapi
On Wed, May 23, 2012 at 11:17 AM, Ritesh Raj Sarraf wrote: > 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 port), > but 80/443 is owned by web servers and xapi is not a web server. Well, technically it is a web server, since it speaks HTTP and serves an XML-RPC based API ;) But yes, I see your point. This is an artifact of xapi being from XenServer, where you would never, ever want to put another web server in dom0. And still, even with xapi on Debian, we still wouldn't recommend someone do this, which is why xapi's binding ports aren't configurable. It shouldn't be too hard make xapi configurable, so that you can change a conf file setting and tell it to listen on a different port, for both HTTP and HTTPS traffic. Is this something that is highly desirable for Wheezy? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674132: [Pkg-xen-devel] Bug#674132: xcp-xapi: backend check error
On Wed, May 23, 2012 at 10:25 AM, Ritesh Raj Sarraf wrote:
> 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}" != "xapi" ]; then
> log_failure_msg "Xen toolstack is not set to xapi! Exiting."
> exit 0
> fi
>
>
> Please fix this to one.
Hi Ritesh,
Should this really be an error? It's likely that for Xen 4.1, someone
might have three toolstacks installed at the same time: xm, xl, and
xapi. It seems that they should have the option to switch between the
three without causing an error in the init scripts of the other two.
In this case, do we really want to return an error here?
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674088: [Pkg-xen-devel] Bug#674088: xcp-xapi: vbd-plug to dom0 does not creates /dev/xvd* devices in dom0
On Wed, May 23, 2012 at 1:35 AM, George Shuklin wrote: > Package: xcp-xapi > Version: 1.3.2-6 > Severity: normal > Tags: upstream > > Normally (in 'iso-based' XCP) is possible to attach VDI to dom0. > > That operation usually looks like: > > xe vbd-create vdi-uuid=... vm-uuid=(dom0 uuid) device=N > xe vbd-plug > > I done those steps in xcp-xapi and got success (no error), but no xvd* device > found. > > Here operations log: > > # xe vbd-create vdi-uuid=c95af56f-799f-49ad-a64f-82eca3299b50 > vm-uuid=d859ed1a-760f-9928-b5be-f0ab1790b15f type=Disk mode=RW device=2 > b2e8f7b3-34c4-fe9a-486e-6551b8ba4165 > # xe vbd-plug uuid=b2e8f7b3-34c4-fe9a-486e-6551b8ba4165 > # ls /dev/xv* > ls: cannot access /dev/xv*: No such file or directory Hi George, This is not a bug, but is rather an intended change in behaviour. The xapi released in Debian right now is a snapshot that is somewhere in time between XenServer 6.0 and XenServer 6.1 -- this new behaviour will be standard in XenServer 6.1 (and XCP 1.6). Try looking for your device in /dev/sm//. If you need to mount partitions on that device, do 'kpartx -av ' (and then 'kpartx -dv ' to remove those partitions from the device mapper). This is only a change in dom0 behaviour, not domU. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: xcp-xapi fails to start
On Tue, Jan 31, 2012 at 9:39 PM, Thomas Goirand wrote: > On 01/31/2012 03:11 PM, Ian Campbell wrote: >> On Sun, 2012-01-29 at 06:22 +0800, Thomas Goirand wrote: >>> + Note that if you wish to use Xen with XCP (Xen Cloud Platform), then using >>> + xl is mandatory. >> >> As I've said before I don't think this is correct. The correct value if >> you are using XCP is "xapi" or "xe" or however you decide to word it. >> >> Ian. > > When you choose "xm", then "xl" doesn't work. When you choose "xl", then > "xm" doesn't work. > > Now, whatever the value of TOOLSTACK, we have "xe" that always work. So > there's no consistency, maybe we should make xe to fail if TOOLSTACK is > set to something else than xe? > > I don't mind implementing a wrapper for xe though, which would do the > same thing as the wrappers we have for both xl and xe, and then package > the "real" xe binary in somewhere else. But then I see an issue. It > might well be possible to use xe only to remote-control an XCP server, > in which case Xen might not even be installed on the local computer. In > such case, xe shouldn't be set to fail, because of a wrong value of > TOOLSTACK. > > What's your take on this? What should I do then? Thoughts? > I prefer for xapi to only start when TOOLSTACK=xapi. xe isn't the toolstack, it's just a CLI to xapi, and the TOOLSTACK switch should have nothing to do with whether the user can run xe on that host. This is analogous to how xend would work: setting toolstack to xl doesn't prevent you from running xm, it just prevents xend from running, which makes running xm fairly useless. xe is useful even if xapi isn't running because it can talk to other hosts. In my development branch of xapi, I have set the init script to only start xapi if TOOLSTACK=xapi. I think that this is the way that it should work. (But honestly, I don't care whether it's TOOLSTACK=xapi or TOOSTACK=xe, as long as xapi won't start unless the correct value is set.) Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: xcp-xapi fails to start
On Thu, Jan 19, 2012 at 8:37 PM, Anders Kaseorg wrote: > If I might make a proposal, I think things would be simpler for everyone if > we put the separate toolstacks into separate conflicting packages. Then we > don’t have to deal with /etc/defaults or debconf or user configuration at > all, and each toolstack would know to shut itself down when it got > uninstalled, so that toolstacks don’t need to worry at runtime about other > toolstacks being enabled. > This might be the way to go when Xen 4.2 is released, when xend will be formally deprecated. It might then be a good time to split xend into a separate binary package from the rest of Xen, which could then use xl by default. I can also see that being difficult to implement in a way that won't break existing installations on upgrade. Also, it would be nice to allow the various toolstacks to coexist on the filesystem, and be able to switch in between them without having to uninstall one in place of the other. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: Bug#655301: Bug#655301: Bug#655301: xcp-xapi fails to start
On Thu, Jan 19, 2012 at 9:44 AM, Ritesh Raj Sarraf wrote: > Thank you. Documenting it would be good for now. > Agreed. We can mention this on the How-to wiki page. Should this also go in the README.Debian? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: Bug#655301: Bug#655301: Bug#655301: xcp-xapi fails to start
On Thu, Jan 19, 2012 at 7:47 AM, Ritesh Raj Sarraf wrote: > On Wed, Jan 18, 2012 at 3:00 AM, Thomas Goirand wrote: >> On 01/17/2012 02:47 PM, Ritesh Raj Sarraf wrote: >>> But the problem is, xcp-xapi wants to have xend disabled. >>> >>> [ ... ] >>> >>> So I disabled the xend init file and then ran into this problem. >> >> No wonder why then! Nobody ever wrote/said that you should do that. The >> xend init.d script does a lot more than just starting xend. It also: >> - modprobe the xenfs and xen-evtchn kernel modules >> - mounts /proc/xen as xenfs >> - Starts xenconsoled >> - Starts xenstored >> >> If the above isn't done, then there's no way that XCP, or even Xen, will >> ever work! The only thing that should be disabled is starting xend, all >> the rest should stay. >> > > What do you mean by "disable starting xend" ? > We'd like that the xend init script continue to start the other services that xpi-xapi relies on, but only actually start the xend daemon iff TOOLSTACK=xm. This way we don't have to worry about renaming or splitting init scripts. > For now, just calling the xend stop in the xapi init script should fix > the problem. > Agreed, but as was pointed out to me by Ian Campbell, that's a bit of a hack, since one service shouldn't be allowed to just shut another one down. I was in favour of making this change to xcp-xapi.init temporarily, until the xend init script is modified to only selectively start xend, but I think now that we should instead ask users to work around this issue until we sort out the xend script. The simplest work-around is to ask the user to add the line 'service xend stop' to the user's xcp-xapi.init script. Thomas, I believe that you submitted a patch to xend.init to check TOOLSTACK=xm. Do you know the status of this patch? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: Bug#655301: Bug#655301: xcp-xapi fails to start
On Mon, Jan 16, 2012 at 11:49 PM, Jonathan Ludlam wrote: > I actually ran into a problem very similar to this myself this morning - it > came from the fact that the init scripts were reordered at some point, and I > still had the old init script ordering. > > I sorted it temporarily by starting the scripts by hand - the normal order is: > > 20: xcp-fe, xend, xcp-v6d > 22: xcp-squeezed > 23: xcp-xapi > > If you manually start the scripts in this order does it work? > > It's interesting that your /proc/xen isn't mounted though - that should > happen in the xend init script, and that should have worked. > I think that we put a line in the xcp-xapi init script that quit without error if it found a xend pid file. This means that to start xapi you need to either 1) edit /etc/init.d/xend so that xend is never actually run, or 2) first let xend start, and then do 'service xend stop' to kill xend, and then do a 'service xcp-xapi start'. Neither of those is very attractive. Perhaps we could instead have the user create a /etc/default/xen file, which will contain a "TOOLSTACK=foo" line. If that file exists, and only if TOOLSTACK=xapi, we could then, within the xcp-xapi init script, check to see if xend is running, and if so, shut it down. This allows us to use xend as a common xen init script, but forces the user to explicitly say that they want to use xapi over xend. I would feel better about killing xend from within the xcp-xapi init file if we were to it this way. Thoughts? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: Bug#655301: Bug#655301: Bug#655301: xcp-xapi fails to start
On Tue, Jan 17, 2012 at 6:47 AM, Ritesh Raj Sarraf wrote:
> On 01/17/2012 02:26 AM, Thomas Goirand wrote:
>>> >
>>> > Interestingly there's nothing under /proc/xen.
>> The /etc/init.d/xend init script should have mount xenfs for you. Try to
>> restart it by hand, and see if it does it. xenfs and xen-evtchn modules
>> are also loaded by this init script. Can you also check if they are
>> loaded? If they aren't loaded after doing a /etc/init.d/xend start, then
>> you got an issue here, which really, has nothing to do with XCP.
>
> Yes, running xend mounts /proc/xen.
>
> But the problem is, xcp-xapi wants to have xend disabled.
>
> # Exit with failure if xend is running
> if [ -f /var/run/xend.pid ]; then
> log_failure_msg "/var/run/xend.pid exists; ${NAME} conflicts
> with xend"
> exit 1
> fi
>
>
> So I disabled the xend init file and then ran into this problem. If I
> run xapi with xend enabled, I get the expected err msg.
>
> lnx200-39:~# ls /proc/xen/
> capabilities privcmd xenbus xsd_kva xsd_port
> lnx200-39:~# /etc/init.d/xcp-xapi start
> /var/run/xend.pid exists; xapi conflicts with xend ... failed!
>
Hi Ritesh,
We're in a bit of a bind with the xend init script. Xapi depends on
most of the init script being run (as you've seen), but xend itself
conflicts with xapi. We need to come up with a good solution to this
conflict.
I think it would be best if we could create a file /etc/default/xen
that would let us switch between the xm, xl and xapi toolstacks. Until
then, do you think it would be best to copy the required parts of
xend.init into xcp-xapi.init? Are there any other solutions that we're
overlooking?
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: Bug#655301: xcp-xapi fails to start
On Thu, Jan 12, 2012 at 7:21 AM, Ritesh Raj Sarraf wrote:
> Setting up xcp-fe (0.5.2-3) ...
> Setting up xcp-squeezed (1.3-15) ...
> xc: error: Could not obtain handle on privileged command interface (2 =
> No such file or directory): Internal error
> Fatal error: exception Xenctrl.Error("Unable to open XC interface")
> Setting up xcp-v6d (1.3-15) ...
> Setting up xcp-storage-managers (0.1.1-2) ...
> Setting up xcp-xe (1.3-15) ...
> Setting up xcp-xapi (1.3-15) ...
> Error: Connection refused (calling connect )
> md5sum: /var/lib/xcp/templates.md5: No such file or directory
> Waiting for xapi to signal init complete
>
> failed to detect xapi init complete after 300s
> Setting up xcp-guest-templates (0.1-3) ...
> Setting up xcp-vncterm (0.1-2) ...
>
>
> The connection error is still there. And because of that there's a 300s
> timeout.
>
> This is my cleaned up environement.
> lnx200-39:~# ls /etc/x
> xcp/ xdg/ xen/ xen-tools/ xml/
>
> I'll look more into it.
>
Could you attach the fresh logs from this environment? There should be
a few hundred lines of logs in /var/log/xcp-xapi.log coming from
thread_zero, which is xapi's initialisation bit. Could you attach
that?
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655301: [Pkg-xen-devel] Bug#655301: Bug#655301: xcp-xapi fails to start
On Tue, Jan 10, 2012 at 12:06 PM, Ritesh Raj Sarraf wrote:
> This seems to be happening because of this:
>
> # 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} ]; do
> if [ -e ${XAPI_STARTUP_COOKIE} ]; then
> return 0
> fi
> sleep 1
> RETRY=$(( ${RETRY} + 1 ))
> done
> return 1
> }
>
> The daemon is started with daemon args as:
> DAEMON_ARGS="-daemon -writereadyfile $XAPI_STARTUP_COOKIE
> -writeinitcomplete $XAPI_INIT_COMPLETE_COOKIE"
>
> I admit this bug report was done in a hurry without trying all options.
>
> My wild guess is that the xcp cookies is dependent on the domain uuid.
> In my case, the uuid was carried froward from the other repository. I
> will try this out and update the bug report.
>
> Thank you for getting the packages done. We'll get it in shape for
> wheezy. :-)
>
Hi Ritesh,
It is likely that the uuid's changed in the upgrade because we didn't
handle the file renaming well. Do you have both
/etc/xensource-inventory and /etc/xcp/inventory? The second file is
the correct location. You may be able to copy the uuid from the first
inventory file into the second.
If this doesn't work, could you please attach both inventory files,
and the log file /var/log/xcp-xapi.log to the bug report? Thanks for
testing our software!
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#649285: ITP: vncterm - Provides VNC service for XCP guest VMs
Package: wnpp Version: 1.0; reported 2011-11-19 Severity: wishlist * Package name : xcp-vncterm Version : 1.0 Upstream Author : Simon Rowe * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : Provides VNC service for XCP guest VMs The Xen Cloud Platform (XCP) is an open source enterprise-ready server virtualization and cloud computing platform, delivering the Xen Hypervisor with support for a range of guest operating systems. . This program to expose a virtual machine's serial console as a VNC terminal frame buffer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648691: [Pkg-xen-devel] Bug#648691: ITP: blktap-dkms -- Xen blktap kernel component DKMS package
On Mon, Nov 14, 2011 at 7:29 AM, Ben Hutchings wrote: > On Mon, 2011-11-14 at 14:30 +0800, Thomas Goirand wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Debian Xen Team >> >> * Package name : blktap-dkms > > Is this really still worthwhile? The last I read was that it is to be > replaced by qemu qdisk. > > Ben. > It is still useful. XCP's xapi relies on it, and we're packaging that up for Debian right now. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646727: ITP: xapi-libs - Libraries for XCP's XenAPI Toolstack
Package: wnpp Version: 1.0; reported 2011-20-26 Severity: wishlist X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org * Package name : libxapi-ocaml Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : OCaml runtime libraries for xapi * Package name : libxapi-ocaml-dev Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : OCaml libraries required to build xapi * Package name : libxapi-ocaml-doc Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : Docs for libxapi-ocaml * Package name : xapi-fe Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : Fork-and-exec daemon for xapi This daemon is the fork-and-exec daemon used by xapi. When xapi requires another executable to be run, rather than forking and execing itself, it uses this single-threaded daemon to do it, passing fds to it as required. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646722: ITP: xapi-sm - Storage management drivers for XenAPI
Package: wnpp Version: 1.0; reported 2011-20-26 Severity: wishlist * Package name : xapi-sm Version : 1.0 Upstream Author : Keith Petley * URL : http://xen.org/products/cloudxen.html * License : LGPL2 Description : Storage management drivers for XCP's XenAPI XCP is a server virtualization platform which provides a rich XML-RPC based management API on top of the Xen hypervisor. xen-sm provides storage backend plugins for various storage types that XCP supports. * Package name : xapi-sm-doc Version : 1.0 Upstream Author : Keith Petley * URL : http://xen.org/products/cloudxen.html * License : LGPL2 Description : Docs for xen-sm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646720: ITP: xapi - XCP's XenAPI Toolstack
Package: wnpp Version: 1.0; reported 2011-20-25 Severity: wishlist * Package name : xapi Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : XCP's XenAPI management daemon XCP is a server virtualization platform which provides a rich XML-RPC based management API on top of the Xen hypervisor. xapi is the contorl daemon for XCP's XenAPI. * Package name : xapi-debug Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : Debug tools for XCP's XenAPI management daemon * Package name : xapi-doc Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : Docs for XCP's XenAPI management daemon * Package name : xapi-squeezed Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : A daemon in charge of ballooning xen domains This daemon is part of the XCP toolstack. It takes requests in the form of Xen hypervisor xenstore trees and balloons domains up and down. * Package name : xapi-v6d Version : 1.0 Upstream Author : Rob Hoes * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : The XenAPI feature daemon * Package name : libxapi-ocaml Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : OCaml libraries required to build the XenAPI management daemon * Package name : libxapi-ocaml-dev Version : 1.0 Upstream Author : Dave Scott * URL : http://xen.org/products/cloudxen.html * License : LGPL2 + linking exception Description : OCaml libraries required to build the XenAPI management daemon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646717: ITP: eliloader - XenAPI's bootloader for EL-based guests
Package: wnpp Version: 1.0; reported 2011-20-26 Severity: wishlist * Package name : eliloader Version : 1.0 Upstream Author : Simon Rowe * URL : http://xen.org/products/cloudxen.html * License : LGPL2 Description : XenAPI's bootloader for EL-based guests The Xen Cloud Platform (XCP) is an open source enterprise-ready server virtualization and cloud computing platform, delivering the Xen Hypervisor with support for a range of guest operating systems. This package provides a bootloader for EL-based Linux distributions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
