> >> > > > > > >> > > > > 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. Please do not forget about this: (emoji-pointing-up) > >> > > >> > Yes, that looks like a good solution. I didn't remember that there > >> > is a kernel config option to automatically do the onlining. With > >> > this kernel option enabled, using a udev rule obviously isn't > >> > needed. The kernel option was added in Linux kernel version 4.7, > >> > which might be after the last time I looked at Hyper-V memory hot-add > in detail. > >> > > >> > Michael > >> > > >> > >> Awesome! > >> > >> Last question: Since not having the kernel option by default and also > >> not having the udev rule in some distributions causes the Hyper-V > >> host to eat up all the memory up to the defined limit (and to die > >> eventually), should this be considered as a bug? And if the answer is > >> no, how can I (or anyone) forward the requirement to the publishers to > be solved at the source? > >> > >> Thank you! > >> > > > > It's unclear whether this should be treated as a bug. We certainly > > want the "right" thing to happen as seamlessly as possible, but there > > are tradeoffs. Back when Vitaly Kuznetsov added > > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE, > > I can see there was some debate about whether this option should be > > enabled by default. There was reluctance to do so because of potential > > backwards compatibility problems with other environments. When > > hot-adding real physical memory to a bare-metal server, apparently you > > don't want to automatically online the added memory. By bug I meant the effects on the hypervisor (see above). A guest without proper onlining of newly added memory is currently able to choke the host to standstill. > > On x86/ARM you most likely do (as why plugging in memory in the first > place?) but there are not many bare metal systems which allow that. > > Note, there were some developments after I've added > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE, namely > > commit 5f47adf762b78cae97de58d9ff01d2d44db09467 > Author: David Hildenbrand <david@xxxxxxxxxx> > Date: Mon Apr 6 20:07:44 2020 -0700 > > mm/memory_hotplug: allow to specify a default online_type > > > > > The Ubuntu image you were testing is specifically an image configured > > for use in an Azure VM, so it makes sense to have memory automatically > > onlined by the kernel. So I looked at a generic Ubuntu 18.04 system, > > and it also has this kernel option set by default. But as another > > data point, RHEL/CentOS 8.4 does *not* have the kernel option set. So > > each distro evidently makes their own decision about this. > > Note: Fedora kernels come with > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y as well. > > > But both generic Ubuntu 18.04 and RHEL/CentOS 8.4 have the udev rules. > > The RHEL/CentOS 8.4 udev rule is more sophisticated in that it does > > not online the added memory when running on System/390 and PowerPC. > > I remember that with s390 we certainly don't want all memory to go online > automatically because but I don't remember the reason :-) > So, using the udev rule is the easier solution, it doesn't require a kernel configuration change - but it needs to be added (and managed) by every vendor. Changing the kernel default is not the easiest thing to do due to possible regressions, and it can still be overwritten by vendors. Having CONFIG_HYPERV_BALLOON require CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE seems like a good solution to me, but I'm not the expert here. > > > > I could envision changing the Linux kernel config rules to > > automatically set CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE > whenever > > CONFIG_HYPERV_BALLOON is selected. > > That could work for custom kernels but not for those shipped with > distributions as these will always have CONFIG_HYPERV_BALLOON if Hyper-V > is one of the supported targets (and it likely is). > > > Alternatively, the Kali Linux folks could consider adding the > > appropriate udev rule. > I am in contact with the kali maintainers and forwarded this mail thread to them. > Or just enable CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE. We've > enabled CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE in Fedora in 2016 > and haven't heard many (any?) complaints (besides ppc64 where it was > disabled) since. > > Cc: David who mostly picked up the auto onlining work since. > > -- > Vitaly
