From: Florian M?ller <redacted>

quoted

Von: Michael Kelley (LINUX) [off-list ref]

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Issues showed up when I set up a Kali Linux Guest. I
missed the memory configuration before booting up the
instance, so it started with 1GB of memory, and
ballooning active between 512MB and several TB of memory.
Hyper-V started to allocate more and more memory to this
guest since the reported memory requirements also
increased. The guest kernel didn't see any of that allocated

memory, as far as I can tell.

quoted

Please do not forget about this: (emoji-pointing-up)

Hmmm.  Right off the bat, I don't know how to fix this.  Hyper-V tells the
guest "Here is more memory".  The hv_balloon driver adds the memory (but
doesn't mark it "online"), and sends a positive ACK to Hyper-V.
From Hyper-V's standpoint, it has successfully given the memory to the
guest. But if the guest hasn't onlined the memory and isn't using it, the guest
continues to report high memory pressure.  Hyper-V assigns yet more
memory to the guest, still to no effect.  Having the hv_balloon driver delay
the ACK until the memory comes online is fraught with problems, and of
course Hyper-V has no visibility into whether the guest has onlined the
memory.

This may be one where the guest configuration really must be
correct.   But I'm open to other suggestions for a possible solution.

Michael

From checking the drivers code, it looks like the guest tells only the free and committed
memory, not the total. I can also see considerations about num_pages_onlined in the
committed-calculation.

I see 2 possible options at the moment: Adding num_total to the message (changing the
protocol), or stop reporting if the guest fails to online memory after the first increase. A
third, more complicated option would be checking for not onlined pages (I've seen
functions for that in the code) and adding them to the free value in the report.

Changing the protocol with the Hyper-V host probably isn't practical.  This
wouldn't be a high enough priority issue for the Hyper-V team to make the
needed changes on their side.  The second option also has problems.  We really
don't want to just stop reporting (and I'm not sure what Hyper-V does if the
guest stops reporting), and it's always hard to know how long to wait for user
space to do something.  The third option sounds feasible, though I haven't
looked at the details.

I'd love to write a patch for this if I had a clue how to test and debug it without
rebuilding my kernel all the time.

Feel free to have at it. :-)   I can also put the third option on our list of things to
look at, but it will be in the "when we can get to it" category.

Michael