KVM hypervisor - Windows 32bit VM, RAM up to 2GB usable

Question

I've got a Debian 10 KVM hypervisor, no libvirt or other tool to administrate it, using QEMU scripts. I need a 32bit Windows VM for a legacy app, but on a supported OS (not XP), either Windows 8.1 or 10 32bit. Both Windows 8.1 & 10 present a message «2GB usable» on system properties when 3GB RAM is assigned (the max capable of handling for a 32 bit machine without other techniques I suppose). On the contrary Win XP seems to use 3GB RAM, stating PAE enabled.

Any ideas how to use 3GB RAM on Win 8.1 or 10, 32 bit?

Here's the screenshot of Win 8.1 VM with 3GB RAM (some on Win 10):

Here is the QEMU script to start the VM (I've also tried host CPU, no difference):

#!/bin/sh
SPICE_PORT=3010
MONITOR_PORT=2330
QEMU_AUDIO_DRV=alsa

kvm \
    -M q35 \
    -nodefaults \
    -cpu qemu64 \
`#  -cpu host` \
    -m 3G \
    -mem-path /dev/hugepages \
    -device virtio-balloon-pci \
    -rtc base=localtime \
    -vga qxl \
    -drive file=win8.qcow2,if=virtio,cache-size=16M,cache=writethrough \
    -device virtio-net-pci,netdev=diktyo0 \
    -netdev user,id=diktyo0 \
    -monitor telnet:localhost:${MONITOR_PORT},server,nowait \
    -device virtio-serial \
    -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
    -chardev spicevmc,id=vdagent,debug=0,name=vdagent \
    -spice port=${SPICE_PORT},addr=127.0.0.1,disable-ticketing \
    -device virtserialport,chardev=charchannel1,id=channel1,name=org.spice-space.webdav.0 \
    -chardev spiceport,name=org.spice-space.webdav.0,id=charchannel1 \
    -soundhw ac97 \
    -name "Windows 8.1 x86" \
    -daemonize \

Following shodanshok's advice, I post resource monitor's output (with 4GB total RAM):

Half the memory is reserved by hardware.

I've also increased RAM to 4GB:

Just in case of QXL video driver reserving too much memory, I also changed the line configuring video to:

-device qxl-vga,vgamem_mb=64,ram_size_mb=64,vram_size_mb=64

I may try to change the Seabios, at least the version. Unfortunately in Debian Stable QEMU version is 3.1.0; it's quite old, I wonder if the same behaviour appears in newer versions.

What's going on with the 32-bit Windows? Are you trying to run a 16-bit app?! — Michael Hampton, Nov 21 '20 at 11:02
For 16 bit apps (I still do meet such!) I use dosbox, on Linux or Windows, with great results! MS-DOS and Win 3/3.1 apps. This one is for an app using an ancient version of a custom IBM-based Java, which for some reason crashes on 64 bit systems. The in-house devs don't want to get involved with it, everything runs happily on 32 bit systems, albeit I got the memory constraint. — Krackout, Nov 21 '20 at 11:44
Well that's pretty scary. Anyway, have you considered actually using libvirt? Writing these commands by hand is a maintenance nightmare. — Michael Hampton, Nov 21 '20 at 11:59
Please Michael, I'm very proud of all these hardly found QEMU command switches :P It's an old, standalone, thin on resources hypervisor for obscure uses like this vm. Working pretty well though as is, I wouldn't bother changing it. Yet I don't think libvirt would gave a solution to this issue. It's essentially another way to configure KVM/QEMU. Of course I may be missing something in my config that it's by default enabled when using libvirt. I have a setup in another client using oVirt-libvirt cluster, if I get their permission I'll try to setup a 32 bit Win vm there to check. — Krackout, Nov 21 '20 at 12:18
You don't have a workstation?! How do you get anything done? — Michael Hampton, Nov 21 '20 at 20:08

shodanshok · Accepted Answer · 2020-11-22T18:01:59.233

4

UPDATED ANSWER: as shown in the comments and the updated question, the specific issue was related to a 2 GB hardware memory reservation due to the specific machine type. Switching to an i440fx machine type solved the issue.

ORIGINAL ANSWER (left here because it can help others with similar issues on 32 bit Windows):

Try increasing the user-space memory allocation by using the following command (and rebooting):

bcdedit /set IncreaseUserVa 3072

Please be sure to snapshot you VM before executing the command above (and be sure to have a valid backup).

edited Nov 22 '20 at 18:01

answered Nov 21 '20 at 19:46

shodanshok

44,038
6
98
162

Done, changed successfully, rebooted, saw the new setting with `bcdedit /enum` but still the same, 2GB usable. – Krackout Nov 21 '20 at 21:42
Also tried `/nx AlwaysOn` (was optin) and `/pae ForceEnable`, still 2GB usable. – Krackout Nov 21 '20 at 22:04
Can you follow the advices reported [here](https://support.microsoft.com/en-us/help/978610/the-usable-memory-may-be-less-than-the-installed-memory-on-windows-7-b) and show how memory is mapped according to resource monitor? – shodanshok Nov 21 '20 at 22:23
I updated the answer according to your proposal @shodanshok – Krackout Nov 22 '20 at 09:36
1

Ok, let's try with another machine type - ie: something based on i440fx rather than q35 (you can get the list of all machine types supported via `-M help`) – shodanshok Nov 22 '20 at 10:37
Oh please let i440fx fade into the dustbin of history. It's way outdated and is unlikely to help anything here. – Michael Hampton Nov 22 '20 at 14:49
I agree with Michael Hampton regarding i440fx; that's why it didn't cross my mind to test it. But shodanshok was right! Switching machine type to pc (pc-i440fx-3.1 in the server's QEMU version) did the trick! @shodanshok post it as an answer if you like to accept it. It'll also be easier for others to spot it, instead of looking at comments. Thank you all. – Krackout Nov 22 '20 at 15:58
@MichaelHampton while true, the i440fx platform has a simpler base hardware - which can help debugging problematic guests. Moreover, as you can use specific virtio devices even with an i440fx machine (ie: viostor, netkvm, etc) the performance difference is almost non-existent. The main motivation to have a q35 machine is to provide a UEFI-compatible instance. – shodanshok Nov 22 '20 at 17:50
@MichaelHampton case in point: the default `pc` machine type on RHEL 7.x is an alias for `RHEL 7.6.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.6.0)` – shodanshok Nov 22 '20 at 18:07
@shodanshok Thanks so much! This is the only way I've been able to increase memory on a 32-bit Windows 10 VM. – Branton Davis Sep 01 '21 at 18:42
@MichaelHampton Do you have a better solution, then? This is the only one I've found. – Branton Davis Sep 01 '21 at 18:42

score 0 · Answer 2 · answered Nov 22 '20 at 14:57

I suspect your problem is with hugepages, which you've explicitly asked KVM to use.

    -mem-path /dev/hugepages \

Do you actually have enough hugepages to give the VM the entire 4GB of RAM? I think you probably don't. Check with:

# grep Huge /proc/meminfo           
AnonHugePages:   1325056 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:    1024
HugePages_Free:     1024
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:         2097152 kB

How many total hugepages and how many free? Notice each hugepage is 2MB. With 1024 of them all you have available is 2GB.

So increase the number of hugepages to account for all the memory that your VM (or VMs!) will use.

# sysctl vm.nr_hugepages
vm.nr_hugepages = 1024

# sysctl vm.nr_hugepages=2048
vm.nr_hugepages = 2048

Now you should have enough hugepages to give the VM all of the memory.

# grep Huge /proc/meminfo 
AnonHugePages:   1327104 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:    2048
HugePages_Free:     2048
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:         4194304 kB

Yes @Michael, there are enough huge pages, actually I've assigned most of server's RAM as such since it's not used for anything else. I also tried disabling huge pages for this VM, no difference. — Krackout, Nov 22 '20 at 16:30

KVM hypervisor - Windows 32bit VM, RAM up to 2GB usable

2 Answers2