[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Which QEMU device-model to use for Windows HVM guests???

I know, i know, sorry my mistake, I was replying too fast and hit the wrong reply button... :)

OK well thanks Ian, than answers that question... i appreciate it as always.

On 6/13/2012 9:58 AM, Ian Campbell wrote:
(adding the list back to the CC)

On Wed, 2012-06-13 at 14:43 +0100, cyberhawk001@xxxxxxxxx wrote:
On 6/13/2012 9:31 AM, Ian Campbell wrote:
On Wed, 2012-06-13 at 14:24 +0100, cyberhawk001@xxxxxxxxx wrote:
Just wondering about which QEMU version to use. Looking in the xl.cfg
MAN page, you can choose from "qemu-xen-traditional" or  "qemu-xen",
however i have seen a third one "qemu-dm" WHICH is not listed in the
xl.cfg man page.

I know the "qemu-xen-traditional" device-model is the default one as it
is more stable, compatible and so forth. The "qemu-xen" is the qemu
upstream one and i am sure still not so stable without tweaking, BUT
have read that f you want to use IOMMU (pci passthrough), than
"qemu-xen" doesn't have support or is buggy, or something like that. I
do want to use PCI passthrough so i guess that is not an option.
HOWEVER, i have read people use "qemu-dm" and don't know how different
is that compared to the other two choices.
qemu-dm is just an umbrella term for the device model, it's not a
specific version.
AHH OK i see. SO the qemu-dm is an umbrella term for what? If you
specify that in the VM config file, what does Xen load?
You can't specify it in the config file, it's just a word we use when we
mean either qemu-xen or qemu-xen-traditional. It's not a valid actual

I was curious since i saw this line in a VM config file somewhere:

device_model = "/usr/lib64/xen/bin/qemu-dm"
This is the path to the dm binary to use, you should never need to
specify this (any more, this wasn't true in 4.1 and xend)

"/usr/lib64/xen/bin/qemu-dm" happens to be the binary for


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.