similar to: problems with xl (libxenlight)

libxenlight exports a function libxl_uuid2string which is used internally in several places but has one external caller in xl. The function mainly implements policy so should not be part of the libxenlight API. The extent to which it can be considered mechanism it is not a xen mechanism since UUID''s are not a concept exlusive to xen. The one caller in xl seems to be an

QUESTION: What, if anything, can I do so that I can use xl (in place of xm) with libvirt 1.0.2 and Xen 4.2.1 in Ubuntu 13.04? BACKGROUND: I am testing a fully updated (as of March 27) installation of Ubuntu 13.04 that includes the following packages: libvirt - version 1.0.2-0ubuntu9 xen-hypervisor-4.2-amd64 - version 4.2.1-0ubuntu1 Upon setting TOOLSTACK=xm in /etc/default/xen (as well as

Hi all, this is a non comprehensive list of missing features in libxenlight and\or xl: - xen_platform_pci flag support in VM config files; - relative paths support in VM config files; - hap support in VM config files; - -c option to xl create; - remus; - trigger command; - tmem-* commands; - sched-* commands; - usb-* commands; - scsi-* commands. In general if you execute "xm

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory XSA-57 version 3 libxl allows guest write access to sensitive console related xenstore keys UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The libxenlight (libxl) toolstack library does not correctly set permissions on

Package: xen-utils-common Version: 4.1.2-1 Severity: normal Hi, I was doing some experiments today with XL TOOLSTACK, and found few problems when trying to do PV domU boot. I was trying to run kfreebsd9 or linux-3.2 kernel in qemu using PV i386, and with simple configuration without any disks, nics or virtual framebuffer, kernel boots (and then kernel itselfs correctly fails with information

Package: xen-utils-common Version: 4.1.2-1 Severity: important Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Witold Baryluk <baryluk at smp.if.uj.edu.pl> To: Debian Bug Tracking System <submit at bugs.debian.org> Subject: /usr/lib/xen-common/bin/xen-toolstack-wrapper: xl create fails because of missing /var/lib/xen

Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com> --- tools/ocaml/Makefile | 2 +- tools/ocaml/common.make | 2 +- tools/ocaml/libs/xl/xl.ml | 209 ++++++++++++ tools/ocaml/libs/xl/xl.mli | 209 ++++++++++++ tools/ocaml/libs/xl/xl_stubs.c | 706 ++++++++++++++++++++++++++++++++++++++++ 5 files changed, 1126 insertions(+), 2 deletions(-)

Package: xen-utils-common Version: 4.1.2-7 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, The script /usr/lib/xen-common/bin/xen-toolstack improperly aborts if *either* `xm` or `xl` cannot be found in the xen-dir (/usr/lib/xen-4.0/bin). This means that a default installation (e.g. following Debian wiki on the subject, namely installing xen-linux-system and

On Tue, 2013-10-22 at 11:52 +0200, PASZTOR Gyorgy wrote: > When you use xl toolstack, you can't reboot domUs. > When you switch back to xm toolstack, than reboot works again. > I think the problem with the debian packaged version is the same as in > this thread: > http://lists.xen.org/archives/html/xen-devel/2011-09/msg01289.html > I also think it's a security issue,

I''ve migrated my Dom0 host to Xen 4.2.0 + xl toolstack. With ''xm'' toolstack, configs in /etc/xen/auto are autostarted, assuming xend/xendomains services are started. IIUC, when using xl toolstack, those services are not to be started; and, afaict, the installation process for 4.2 has them disabled by default. Now, the configs in /etc/xen/auto are simply ignored. I

Hi, "Ian Campbell" <ijc at hellion.org.uk> ?rta 2013-10-22 11:17-kor: > On Tue, 2013-10-22 at 11:52 +0200, PASZTOR Gyorgy wrote: > > When you use xl toolstack, you can't reboot domUs. > > When you switch back to xm toolstack, than reboot works again. > > I think the problem with the debian packaged version is the same as in > > this thread: > >

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: important Tags: security patch When you use xl toolstack, you can't reboot domUs. When you switch back to xm toolstack, than reboot works again. I think the problem with the debian packaged version is the same as in this thread: http://lists.xen.org/archives/html/xen-devel/2011-09/msg01289.html I also think it's a security issue,

Hi, I just finished preparing the Xen-4.5 merge from experimental into our next release (Vivid/15.04). And something I actually should have done since the 4.4 times is to report back the delta I have in case there are things Debian might want to pick up as well. So below is the commented debdiff between the 4.5.0-1 in experimental and the Ubuntu version I prepared so far (only compile tested on

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: xen-utils-common Version: 4.1.2-1 Severity: important Dear Maintainer, I changed toolstack to xl in /etc/default/xen, rebooted machine, and xl started working, but creating domU (kfreebsd9 from package kfreebsd-image-9.0-1-xen) fails, because /var/lib/xen is missing. Just doing 'mkdir /var/lib/xen' solved my problem, and kfreebsd9 kernel now loads (still panics because of lack

I get “Unable to connect to libvirt” when using virt-manager in combination with the XL toolstack and Xen 4.2.1. (No problems when using virt-manager in combination with the XM toolstack.) More details of the situation can be found in a bug-report that I filed on launchpad. Please see: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1180281 Judging from the information that I provided

Hej folks, I''m messing around with DRBD once again but with a new Xen 4.1.2 installation using the XL toolstack instead of the xend daemon. However, after getting my DRBD installed and a device operational, trying to create a domU using the drbd block device doesn''t want to work: xl create -c test.cfg Parsing config file test.cfg Unknown disk type: drbd My config has: disk

Hi all. I recently compiled xen 4.1.3 on Fedora 17(64 bit). The xen entry appears in the grub. Inspite of booting Fedora, with xen hypervisor entry , when I start virt-manager, I get an error " Internal Error : libxenlight state driver is not active " Can anyone help me on this? -- Rohit S Damkondwar B.Tech Computer Engineering CoEP MyBlog

Package: xen-utils-4.2 Version: 4.2.0-1 Severity: normal Hello, xl is supposed to be current tool for managing virtual machines on xen (in absence of any working GUI for that in Debian). However, xl produces this: # xl list ERROR: A different toolstack (xm) have been selected! There is no info in README.Debian I could find how to cahnge this selection. Reportedly both xl and xm work

Ian Campbell wrote: > On Mon, 2013-09-09 at 03:29 +0000, Liu, Jinsong wrote: >> From 18344216b432648605726b137b348f28ef64a4ef Mon Sep 17 00:00:00 >> 2001 >> From: Liu Jinsong <jinsong.liu@intel.com> >> Date: Fri, 23 Aug 2013 23:30:23 +0800 >> Subject: [PATCH V3] xl: HVM domain S3 bugfix >> >> Currently Xen hvm s3 has a bug coming from the