similar to: /usr/lib/xen/bin/qemu-dm: invalid option -- ''-vcpu_avail''

Hi. I can''t use the vnc option (VNC=1 in my xmexample.hvm file), when I use RedHat or Fedora on 64 bits. The qemu log, say /usr/lib64/xen/bin/qemu-dm: invalid option -- ''-vncconnect'' But when I use RedHat or Fedora 32 bits, works fine. There is a problem or incompatibility in the 64 bits Xen kernel and the VNC option ? Best regards Luis

Hi, I believe the package is ready: http://ftparchive.gplhost.com/debian/pool/lenny/main/x/xen-qemu-dm-3.4/xen-qemu-dm-3.4_3.4.2-1.dsc I asked Ian Jackson to sponsor it (he works for Citrix and is a DD), but it's been 2 weeks, and he seems busy with work. I'd be glad if someone was sponsoring the upload of this package in Debian SID, soon enough so that people will be able to test it

Hi, I believe the package is ready: http://ftparchive.gplhost.com/debian/pool/lenny/main/x/xen-qemu-dm-3.4/xen-qemu-dm-3.4_3.4.2-1.dsc I asked Ian Jackson to sponsor it (he works for Citrix and is a DD), but it's been 2 weeks, and he seems busy with work. I'd be glad if someone was sponsoring the upload of this package in Debian SID, soon enough so that people will be able to test it

Hi, I have set maxvcpus and vcpus options in my domU configuration file, and I can see that X number of vcpu are set for the domU. I tried to activate all the vpcus by using vpcu_avail option (using decimal to represent vpcu bitmask e.g. 24=11000) but it doesn''t seem to work, and only the first vpcu is activated (i.e. has -b- state) while all other vpcu''s set for the domU are

Hi, I have set maxvcpus and vcpus options in my domU configuration file, and I can see that X number of vcpu are set for the domU. I tried to activate all the vpcus by using vpcu_avail option (using decimal to represent vpcu bitmask e.g. 24=11000) but it doesn''t seem to work, and only the first vpcu is activated (i.e. has -b- state) while all other vpcu''s set for the domU are

Package: xcp-xapi Version: 1.3-16 Severity: normal Tags: patch Dear Maintainer, Path to "xe" program in /usr/lib/xcp/bin/xe-mount-iso-sr should be: XE="/usr/bin/xe" HTH, David -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)

Hi, I'm trying to solve this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615797 As much as I can tell, and unless I have missed something, the issue is a missing -lpulse in the Makefile.target (see attached diff file that fixes the issue). While my patch makes it compile again, I fear that I'm not doing well, and that there must be a better way to fix, that would take care of

Hi, I'm trying to solve this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615797 As much as I can tell, and unless I have missed something, the issue is a missing -lpulse in the Makefile.target (see attached diff file that fixes the issue). While my patch makes it compile again, I fear that I'm not doing well, and that there must be a better way to fix, that would take care of

Package: xcp-xapi Version: 1.3.2-6 Severity: minor Tags: upstream Builin utility for lowlevel vm boot repairment xe-edit-bootloader contains wrong path to xe. IS: XE="/usr/lib/xcp/bin/xe" MUST BE: XE="/usr/bin/xe" -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux

Hi, When I first built my Debian package, I needed to depend on qemu-system | qemu, since there was no other ways to pull needed BIOS files. It seems the situation changed, and that I could depend on less stuff from the qemu package. Maybe only the package named "etherboot" and "vgabios". To do that, my plan is to simply package a folder named: /usr/share/xen/qemu with in

Hi, When I first built my Debian package, I needed to depend on qemu-system | qemu, since there was no other ways to pull needed BIOS files. It seems the situation changed, and that I could depend on less stuff from the qemu package. Maybe only the package named "etherboot" and "vgabios". To do that, my plan is to simply package a folder named: /usr/share/xen/qemu with in

Hi, i want to start domain with 2 cpus avail, but also have the opportunity to change on-the-fly the number of cpus to, for example, 4. in my domain.cfg i have: vcpus = 2 vcpu_avail = 7 The domain starts with 2 cpus, as expected, but rising the number does not work. It silently fails. Lowering the number works as expected. $ xm vcpu-set domain 3 $ xm list Name

Package: xen-hypervisor-4.1-amd64 Version: 4.1.4-2 This is related to Bug#699237: Huawei E220 does not work under Debian Wheezy Mainboard Gigabyte Z77X-D3H, 32GB RAM Xen dom0: Debian Wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux - affected 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux - affected Bus 001 Device 004: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA

On 04/27/2011 04:23 AM, Niccol? Belli wrote: > Hi, I backported xen-4.1-2 to Squeeze, but when I try to build > xen-qemu-dm-4.0 against it, it doesn't build. > Can you please help me? I attached log file. > > Niccol? Hi, To me, this looks like an issue with libxen-dev. The file /usr/include/xenctrl.h is the one to blame in your build log... Please write to the pkg-xen list

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

Il 27/04/2011 14:37, Ian Campbell ha scritto: > Which specific revision of qemu-xen-4.1 are you using? I'm using a tarball from http://bits.xensource.com/oss-xen/release/4.1.0/xen-4.1.0.tar.gz It seems Thomas used the tools/ioemu-qemu-xen subdirectory as source for xen-qemu-dm. At a first glance I didn't notice debian/mypatches/add-rules.patch: it adds Rules.mk from the tools

Hi! Attached patch makes xen-tools and stubdom-dm going independent from hardcoded pathes. It is no possible to install into /usr/local or any other non-default directory and use it out-of-the box. This allows us to have different Xen versions in different directories, simplifies packaging for distributions. It also finds ''hvmloader'' and

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: grave I tried to start an HVM guest to setup Windows 2003 64 bits entreprise R2, and I spent a long time figuring out that there is no /usr/lib/xen folder by default, and this is where Xen is searching for it's file when using HVM, VNC and all. Doing a simple symlink with ln -s /usr/lib/xen-3.2.1 /usr/lib/xen made it working, if it's not

On Wed, 2014-01-01 at 09:52 -0600, Marc F. Clemente wrote: > I have seen posts mentioning "traditional" and "upstream" qemu-dm. > But it is not clear to me what the difference is between "traditional" > and "upstream", or how to select either one. This is explained in the xl.cfg(5) man page. http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html

Package: xen-utils-4.3 Version: 4.3.0-3+b1 Severity: normal When I try to create an HVW withDevian/xen, I run into trouble. It used to work, maybe with xen 4.1, but it has never worked since. Bug 688311 was filed, with the same exact problem. That bug was somehow closed and no resolution or explanation was provided. I have seen posts mentioning "traditional" and "upstream"