[Pkg-xen-devel] Bug#733865: Bug#733865: Bug#733865: xen-utils-4.3: qemu-dm is not executable: No such file or directory

[Ian Campbell]

On Mon, 2014-01-06 at 05:29 -0600, Marc F. Clemente wrote:
> 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"

Yes, I think so. Not sure what the default path is, but it probably
isn't correct so the override is appropriate.

> > 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.

IIRC it was removed from the package when Debian's xen went to 4.0, but
re-added as a separate source package. Then when Debian's Xen went to
4.1 it was reenabled in the main Xen package and the separate source
package was obsoleted. Then it went away again with the 4.2 packages.

> > 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"?

It ought to be possible, the upstream release still includes it so you
could download it and give it a try, I've never done it myself.

You might find the Squeeze era xen-qemu-dm-4.0 source package
illustrative.

> 
> >> 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.

There have been various IOMMU issues relating to buggy hardware where
"buggy" is not stability but rather security related. The one I can
think of immediately was XSA-36 but that was an AMD thing IIRC, and you
are using Intel. I'm pretty sure there were Intel ones too.

Check the list of XSAs (Xen Security Announcements) if one of them
appears related then the text will describe what the security issue was
you can make a determination if it is an issue which affects you -- and
from there I think it will also explain how to turn it back on if you
think you are safe (or you could check the Xen command line option
docs).

> I wonder if anybody else shares my experience...

WTR the IOMMU disabling due to security issue, loads, I'm sure google
will find them.

Ian.