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

[Xen-users] matching Qemu version to Xen version, how critical?


there have been several posts lately, like the above, but not as complete as it, but they all go like this:
I install xen-4.x (usually 4.8) on Stretch and try to launch a Windows install VM. It either never starts or I
run out of memory before I'm done.

But in the above, Mr. Jaser goes further and tries a source build of xen-4.9 (in Stretch) and there is no such trouble.

All the recent Xen packages for Ubuntu and Debian do not match Qemu version with Xen as found in upstream.
In other words:

Ubuntu Artful: qemu->2.10, xen->4.9. upstream has qemu->2.8

Debian Stretch: qemu->2.8, xen->4.8. Should be qemu->2.7

Ubuntu Zesty: same as Stretch

Ubuntu Xenial: qemu->2.5, xen->4.6. Should be qemu->2.2

Artful has the largest deviation between distro and upstream for qemu version.
Certainly, the distro builds are good in the sense that both Xen and Qemu share the same basic libraries
during build. So as long as they build and install, things should be OK?

When we do a source build none of this issue comes up, since Qemu sources are carried via git and tarball.

I've recently done a port of the Artful xen-4.9 to Stretch and I finished the Xen build in Stretch before I realized that
qemu in Artful depends on the libxen-4.9 headers and libraries.

So I went further and did a build of qemu-2.8 for Stretch with matching xen-4.9 libraries.

I already have done this with success for xen-4.8, by building qemu-2.7 with xen-4.8 libraries. This combo installs and tests well, launching and running a Win7 VM. I've yet to test my Xen-4.9 combo for Stretch.

Please tell me it doesn't matter what version of qemu is used with Xen, as long as they are build together. How critical can it be?

##xen-packaging on freenode IRC

Xen-users mailing list



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