Am 2017-09-23 18:01, schrieb Michael Tokarev:
On Thu, 10 Aug 2017 14:45:56 -0400 "Michael J. Redd"
<micr...@gmail.com> wrote:
Package: qemu-system-x86Version: 1:2.8+dfsg-6+deb9u2
Problem:======Latest Stretch `qemu-system-i386` process consumes the
majority of Xen Dom0's RAM, ultimately crashes DomU.
Does this happen with version 1:2.8+dfsg-6+deb9u1 too?
No, I think not. Will retest and report back.
Does this happen with qemu-system-x86_64?
Both of these versions include the same patch from upstream, but a
bit different incarnations of it. I suspect that both are having
probs here.
Please note that -i386 version (32bit) isn't being often tested these
days,
most development/testing is done with -x86_64 version, so please switch
to
the -x86_64 version if that works.
The problem I use i386 is that Debians 64bit-Xen package is compiled
with...
./configure \
--disable-docs --disable-stubdom --disable-xen \
--prefix=/usr \
--includedir=/usr/include \
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--sysconfdir=/etc \
--localstatedir=/var \
--with-libexec-leaf-dir=xen-$(VERSION) \
--disable-blktap1 \
--disable-blktap2 \
--disable-ocamltools \
--disable-qemu-traditional --disable-rombios \
--with-system-qemu=/usr/bin/qemu-system-i386 \
--with-system-seabios=/usr/share/seabios/bios-256k.bin
I use Ganeti with Xen and have configured my cluster to use x86_64 but
no chance > Xen always starts i386 qemu.
The last years I was recompiling Xen because of this, but gave up some
months ago. Doing this on every update made me go nuts.
Will recompile and report back soon.
Due to the same reason, I don't see why severity of this bug should be
raised, -- if it were actually not working with 64bit version of qemu,
it'd be quite noizy due to all xen users complaining.
Still, it'd be nice to find and fix the issue.
Thanks,
/mjt
In the meantime I did some more tests and updated Xen to 4.8.1-1+deb9u3
> no change.
But I've found out, that this problem only happens when I start a
"Windows 2008 r2" instance on the host. Maybe "Windows 7" triggers the
same problem?!.
As long as I only start "Windows 2012 r2" or "Windows 8.1" the problem
does not occur.
Updating the PV drivers inside Windows 2008 r2 instance from 8.1.0 to
8.2.0 did not help.
