Comment 6 for bug 1916313

> First of all, 2C16G40G is my vm flavor specification(2 vcpus, 16G ram,
> 40G disk), and this issue occurred regardless of what ram configured.

Thanks for clarifying

> In short, this issue is that the compute node will allocated 16G ram by
> `top -p <vm-process>` when I boot a 16G ram windows vm instead of the
> actual ram.

Ok, that is odd but then a windows behavior and nothing that qemu/kvm "do".
There are only a few things the host can do to influence this, mostly the so
called HV-enlightenments which you can control.
https://github.com/qemu/qemu/blob/master/docs/hyperv.txt
But none of those I'd know to be about memory allocation.

And if not this, then this is about windows configuration. But I can't
add a windows bug-task here :-)

I'd be more concerned if you'd say up to Ubuntu/qemu version X this
was fine, but now with version Y the guest behaves differently.
But as far as I understood this always was the case for your setup right?

> On the contrary, the linux VM I boot will allocate actual ram by top
> command.

Still you'll see it converge onto all-ram over it's life-cycle due to caches.

Also be careful that for checking memory consumption top is probably
the least reliable tool.
There is always "more detail", but I'd at least use the following:
For a guest I had "h-qemu-modules"
  $ pidstat -p $(pgrep -f 'name guest=h-qemu-modules') -T ALL -tr 5
And in general only care about RSS not VSS in any of those tools.
Actually even RSS can't be just added up, but that is a different topic.

> And I have to execute `virsh qemu-monitor-command <instance-id> --hmp
> "balloon <size>"` manually to decrease the ram in order to achieve
> allocate more ram.

Well, it would not have any other chance. By increasing the balloon
you steal away
that much from the guest and free it up from the Hosts POV. No
surprise on this one.