Re: [Xen-users] dom0 memory issue with Win10 domU - debian stretch xen 4.8.1

[Mark Pryor <tlviewer@xxxxxxxxx>]

Hello,

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:

/etc/default/xencommons

PryMar56

##xen-packaging on Freenode IRC

On Sunday, October 1, 2017 1:48 PM, John Jaser <john@xxxxxxxxx> wrote:

Greetings:

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.

best,

John Jaser

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users