- 1 Using upstream qemu with xen
- 2 Why xen builds qemu
- 3 When xen builds qemu
- 4 Specifying your distribution version of qemu
- 5 Where xen builds qemu
- 6 How xen builds qemu
- 7 Overriding QEMU URL and revision
- 8 Device model for qemu
- 9 Installing your own qemu
- 10 Use with SeaBIOS
- 11 New features
- 12 Difference with qemu-xen-traditional
Using upstream qemu with xen
This page explains how you should be building xen when using an upstream version of qemu, or your own distribution specific version of qemu. It also explains why xen historically has built qemu itself, and the different versions of not-upstream version of qemu.
Why xen builds qemu
Historicaloy xen has built qemu as xen originally had a trimmed down version of qemu to enable the guest to work with the xen hypervisor. Is all required code now upstream?
It is perfectly reasonable for xen to not have to qemu and you should be able to run own distribution version of qemu so long as its as new as the currently recommended version of qemu (determine this and document it on the git tree?).
When xen builds qemu
xen will build qemu by default if your target is x86, x86_64. Building qemu is disabled by default when building xen for other architectures.
Specifying your distribution version of qemu
You can specify that you don't want to build qemu and refer to your distribution specific version of qemu by using:
When using this the xen build system will use this for the default path for calling qemu. If you do not specify a path by default xen will be built to call
qemu-system-i386, and your system's default search path will be used. Note that xen uses
qemu-system-i386 as the default qemu given that when xen builds qemu the resulting qemu binary will be called qemu-system-i386 for both x86 and x86_64 (fix this ? Actually why not remove all this building qemu crap from xen?). If you want to specify an exact path for qemu to use for a guest after you have built xen you can do so by specifying it under the xl
device_model_version field in the guest configuration as shown further below.
Where xen builds qemu
If xen will build qemu it will build it under the
How xen builds qemu
When running make when building xen in the xen git tree the enabled qemu targets will be built and by default on x86 and x86_64 two targets are built:
* CONFIG_QEMU_TRAD: checks out the git tree defined by CONFIG_QEMU git://xenbits.xen.org/qemu-xen-unstable.git * CONFIG_QEMU_XEN: checks out the git tree defined by QEMU_UPSTREAM_URL git://xenbits.xen.org/qemu-upstream-unstable.git
Add here documentation explaining the difference between these two. I suspect we only prefer to use the upstream version now?
Overriding QEMU URL and revision
If you'd like to modify the URL so that the another upstream version of qemu is used, and override the branch used you can edit your "xen/.Config.mk" file, for example:
QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git QEMU_UPSTREAM_REVISION = master
As of 2014-01-22 the revision used by xen is 'qemu-xen-4.4.0-rc1', using the 'git://xenbits.xen.org/qemu-upstream-unstable.git' tree.
Device model for qemu
Which qemu is used by your vm is controlled by the device_model_version xl field in your vm configuration. These days you can use the distribution provided version of xemu directly. For example to use your distribution x86-64 version of qemu you would use:
device_model_version = "/usr/bin/qemu-system-x86_64"
Installing your own qemu
* Get Xen source from the xen git tree * Get QEMU upstream source from: ** git://git.qemu.org/qemu.git
Build your own qemu
- Build Xen
make xen tools
If it fail see bellow.
- Build QEMU upstream with Xen
./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
Troubleshooting compilation errors: If you get an error from configure like "ERROR: User requested feature xen ERROR: configure was not able to find it" then see this: http://xen.1045712.n5.nabble.com/Upstream-Qemu-With-Xen-configuration-problem-td4561779.html , ie. you need to point the paths for "configure" to xen source directory, not to xen dist directory.
- With the latest xen-unstable tree, use:
- device_model_version = 'qemu-xen'
- device_model_override = '/root/work/qemu/_build/i386-softmmu/qemu-system-i386'
Now xl will always try run qemu upstream with seabios, so build xen with seabios.
- For troubleshooting device_model on older Xen related errors (Xen specific options -domain-name, -vcpus, etc) see: http://xen.1045712.n5.nabble.com/Upstream-QEMU-not-working-with-Xen-unstable-lacks-option-definitions-td4372252.html
Use with SeaBIOS
SeaBIOS support is now fully integrated into the Xen build system and is always used when using device_model_version = "qemu-xen". You can also specify your bios preference explicitly by using in your vm config:
bios = "seabios"
If you want to build a version of SeaBIOS other than the default then you can override SEABIOS_UPSTREAM_URL and/or SEABIOS_UPSTREAM_TAG via .config. For reference the upstream SeaBIOS repository is [].
It's the PV drivers from KVM world. To use it for network, just use 'virtio-net' as a model:
vif = [ 'model=virtio-net' ]
You will need those kernel modules to use a VirtIO device
virtio_mmio virtio_pci virtio_net
SPICE / QXL
SPICE is another remote-display protocol and QXL is a PV framebuffer which uses the best of the SPICE capabilities. To activate SPICE you can add this in the VM config file (this works only with xl).
spice=1 spicehost='0.0.0.0' spiceport=6000 spicedisable_ticketing=1
If you wish to use QXL as well you have to add:
device_model_args_hvm = [ '-vga', 'qxl' ] videoram = 128
QXL does not currently work under Xen due to some limitation. (check [this email] for more information.)
Difference with qemu-xen-traditional
Missing feature from the good old qemu-dm
Currently, there is few missing feature that not supported by QEMU upstream, but the work is ongoing.
- dirty log: This is needed to migrate a guest. Patches have been posted to both QEMU and libxl, but are not applied yet.
- VGA passthrough: Sometime (all the time?), simple PCI passthrough does not works for graphics card. The few things that are done in qemu-dm are not yet upstreamed.
New feature from QEMU upstream
There are some benefits from upstreaming the support of Xen to QEMU. We can now use:
- VirtIO as an alternative to Xen PV drivers
- SPICE, as a remote-display protocol instead of the old VNC.
- different kind of file format for a disc.
- the ability to connect several times to the VNC server.