Re: dom0 memory issue with Win10 domU - debian stretch xen 4.8.1
A similar qemu-version-clash has recently happened in Fc26, as users naturally want to use the latest qemu, while Xen-4.8 is tied to an older qemu version.
The Xen source tarball in Stretch is shortened from the full upstream, by removing
tools/qemu-xen* and extras/
Now qemu-system-i386 is provided by a separate, distro package (qemu-system-x86), not within Xen.
Here I have a source build of the full upstream Xen-4.8. Checking qemu version:
$/usr/lib/xen/bin/qemu-system-i386 -version QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
As you noted, Stretch now provides qemu 2.8.
Its now up to the Debian users of xen-hypervisor*deb, etc to insure that qemu-system-i386 (2.7) is available to Xen. Its not clear that there is a definite way to do this. In Fedora, they could roll back the version, since multiple versions of qemu-system-x86 were kept.
It may be that multiple versions of qemu* are needed in the file system.
However its done, the resulting path to qemu* 2.7 can be configured here:
##xen-packaging on Freenode IRC
On Sunday, October 1, 2017 1:48 PM, John Jaser <[hidden email]> wrote:
I ran into an issue in production that I am able to reproduce in lab on clean installs: The qemu process rapidly consumes all dom0 memory. Wondering if anyone else has seen this?
debian stretch with packaged xen 4.8.1 on various amd64 hosts
boot from CD: Windows 10 Professional, build 1703, 32-bit ISO
disk is raw ceph rbd (or local loop file- same result)
use xlexample.hvm with changes:
viridian = 1
memory = 2048
vcpus = 2
vif = [ "mac=00:16:3e:00:02:11, bridge=br0" ]
disk = [ '/dev/rbd/rbd/diskimg_win10Pro32_clean,raw,xvda,rw', '/home/john/iso/win10Pro32.iso,,xvdb,r,cdrom' ]
vnc = 1
With above configuration, everything launches fine, but qemu-system-i386 for the domU will start using all available memory until the qemu process is reaped by oom-reaper.
Uninstalling the packaged xen 4.8.1 and installing xen 4.9.0 from source- the issue is resolved.
I do see that debian xen package 4.8.1 uses qemu 2.8.1, while source 4.9.0 compiled qemu 2.8.0.