Marc F. Clemente
2014-Jan-01 15:52 UTC
[Pkg-xen-devel] Bug#733865: xen-utils-4.3: qemu-dm is not executable: No such file or directory
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" qemu-dm. But it is not clear to me what the difference is between "traditional" and "upstream", or how to select either one. My config file (snaptest.cfg) is nearly identical to the one provided by the distribution in /etc/xen/xlexample.hvm. I don't know if there are missing files in the distibution. Or if I am missing an important package. Or maybe I'm doing something wrong- and the documentation is inaccurate. Is it possible to do HVM with Debian? Thanks, Marc # xl create snaptest.cfg Parsing config from snaptest.cfg xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->00000000001a0164 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->00000000ff800000 ENTRY ADDRESS: 0000000000100608 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000005fb 1GB PAGES: 0x0000000000000001 libxl: error: libxl_dm.c:1142:libxl__spawn_local_dm: device model /usr/lib/xen-4.3/bin/qemu-dm is not executable: No such file or directory libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: (null): spawn failed (rc=-3) libxl: error: libxl_create.c:1075:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1300:libxl__destroy_device_model: could not find device-model's pid for dom 2 libxl: error: libxl.c:1408:libxl__destroy_domid: libxl__destroy_device_model failed for 2 Exit 3 # cat snaptest.cfg builder='hvm' name = "example.hvm" memory = 4096 vcpus = 2 disk = [ 'phy:/dev/vg0/snap,hda,w' ] -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (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 xen-utils-4.3 depends on: ii e2fslibs 1.42.8-1 ii libc6 2.17-97 ii libncurses5 5.9+20130608-1 ii libtinfo5 5.9+20130608-1 ii libxen-4.3 4.3.0-3+b1 ii libxenstore3.0 4.3.0-3+b1 ii libyajl2 2.0.4-4 ii python2.7 2.7.6-3 pn python:any <none> ii xen-utils-common 4.3.0-3 Versions of packages xen-utils-4.3 recommends: ii bridge-utils 1.5-7 ii qemu-system-x86 1.7.0+dfsg-2 ii xen-hypervisor-4.3-amd64 [xen-hypervisor-4.3] 4.3.0-3+b1 xen-utils-4.3 suggests no packages. -- no debconf information
Ian Campbell
2014-Jan-02 17:56 UTC
[Pkg-xen-devel] Bug#733865: Bug#733865: xen-utils-4.3: qemu-dm is not executable: No such file or directory
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 Briefly: "traditional" is the historical Xen fork of Qemu (0.7 or 0.8 ish, ancient), this was the default qemu used for HVM guests until Xen 4.4. "upstream" is the upstream (i.e. qemu.org) version of Qemu which can be used with Xen since 4.1 or 4.2 (I forget exactly) and became the default in 4.4. You can select a non-default model use by using the "device_model_version" directive in your config. In the context of Debian the Debian Xen maintainer has been trying to move away from the traditional fork for several releases. Historically the traditional qemu was shipped with the Xen utils in but in some release (Wheezy? Maybe Squeeze?) it was removed and ended up packaged separately as a separate xen-qemu-dm-4.0 package in order to keep things working. In Jessie even that is gone. Luckily however the upstream qemu package in Jessie already supports Xen so you should be able to simply select that in your configuration. So, things are a bit in flux right now but will be sorted by the time Jessie is actually released. The fact that the Xen tools in 4.3 still default to qemu-traditional which is not present is a bit unfortunate but with Xen 4.4 due to be released in the next 4-6 weeks with a default of qemu-upstream this will take care of itself sooner rather than later. Xen 4.4 also includes support for compiling without qemu-traditional support which will improve the error message should you try to use it (either inadvertently as you have done here or deliberately).> I don't know if there are missing files in the distibution. Or if I > am missing an important package.xen-utils-4.3 recommends qemu-system-x86 which I think is the one you want for qemu-upstream support and you seem to have it installed.> Or maybe I'm doing something wrong- and the documentation is > inaccurate. > > Is it possible to do HVM with Debian?It should be, although as I say it may be in flux a bit. Ian
Marc F. Clemente
2014-Jan-06 11:29 UTC
[Pkg-xen-devel] Bug#733865: Bug#733865: xen-utils-4.3: qemu-dm is not executable: No such file or directory
On 01/02/2014 11:56 AM, Ian Campbell wrote:> You can select a non-default model use by using the > "device_model_version" directive in your config.From what I gather, for now, you MUST select a non-default model, using something like: device_model_version="qemu-xen" device_model_override="/usr/bin/qemu-system-x86_64"> In the context of Debian the Debian Xen maintainer has been trying to > move away from the traditional fork for several releases. Historically > the traditional qemu was shipped with the Xen utils in but in some > release (Wheezy? Maybe Squeeze?) it was removed and ended up packaged > separately as a separate xen-qemu-dm-4.0 package in order to keep things > working. In Jessie even that is gone. Luckily however the upstream qemu > package in Jessie already supports Xen so you should be able to simply > select that in your configuration.So "traditional" disappeared when Debian's xen went from 4.1 to 4.2.> So, things are a bit in flux right now but will be sorted by the time > Jessie is actually released. The fact that the Xen tools in 4.3 still > default to qemu-traditional which is not present is a bit unfortunate > but with Xen 4.4 due to be released in the next 4-6 weeks with a default > of qemu-upstream this will take care of itself sooner rather than later. > Xen 4.4 also includes support for compiling without qemu-traditional > support which will improve the error message should you try to use it > (either inadvertently as you have done here or deliberately).Is it, or will it be possible for me to build xen 4.3 or 4.4 WITH "traditional"?>> Is it possible to do HVM with Debian? > > It should be, although as I say it may be in flux a bit.My problem is that I was doing HVM with xen 4.1. I had MS Windows XP, 7 and 8 virtual machines. I had VGA and PCI passthrough working just fine. I tried using xen 4.2, but I was unable to do VGA passthrough. With 4.3, I can't even do PCI passthrough. It says that my Intel 5500 chipset is buggy (Intel errata #53), and disables IOMMU. Maybe my chipset is buggy... But it is rock-solid stable when I do HVMs with VGA passthrough using xen 4.1. I wonder if anybody else shares my experience... Comments or emails are welcome. Thanks, Marc
Possibly Parallel Threads
- Bug#733865: Bug#733865: xen-utils-4.3: qemu-dm is not executable: No such file or directory
- Bug#733865: xen-utils-4.3: qemu-dm is not executable: No such file or directory
- Bug#688311: xen-utils-4.2: qemu-dm not available
- Bug#776742: xen-utils-common: no support for VGA Passthrough
- Bug#988333: linux-image-5.10.0-6-amd64: VGA Intel IGD Passthrough to Debian Xen HVM DomUs not working, but Windows Xen HVMs do work