View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007552||Kali Linux||[All Projects] General Bug||public||2022-01-29 21:49||2022-06-30 12:41|
|Target Version||Fixed in Version|
|Summary||0007552: Popping Balloons|
|Description||A default Kali installation (or the live cd) in a virtual machine on hyper-v starts eating up all available memory shortly after logging in into xfce. |
The consumption only shows in the hyper-v console, not in the guest itself.
It stops when the max. configured memory is reached. This might be 1TB of ram on a fresh vm without configuration changes, which basically breaks everything. Dynamic memory needs to be enabled for this (by default).
|Steps To Reproduce||Create a new Hyper-V VM. (Recommendation: Don't use quick create.)|
I went with
- Generation 2
- 1GB initial memory with dynamic memory active
- the default switch
- a new Harddrive (5Gb) which won't be used
- and the kali live cd image as boot device
You can also install Kali with the default options, it won't change the result.
Before you start the instance: Edit its properties, disable secure boot and set a reasonable memory limit (16Gb here).
Watch the memory tab in the hyper-v manager once the instance booted. It might take 2-3 minutes for the data to show up. You won't see the consumed memory in the guest itself.
If the issue is reproducable: The memory balloon with grow and ultimately block your system once swapping starts.
|Additional Information||When you run the instance without configuring a lower memory limit (overprovisioning), it will eventually create log entries about unhandled hv_ballooning events. Those happen so rapidly, they wrote 70GB of logs here in less than 20 minutes.|
I tested the same scenario with an ubuntu live cd, it doesn't happen there. Also the rate of updates about the memory usage for the hypervisor is way faster, like one per second. With kali, it's something between 30s and a minute.
The effect only starts after being logged in. There's no difference if it's the regular console of the extended thingie with xrdp. Logging out/closing the console has no effect.
||Sorry about the title, I had to... feel free to change that to something more suitable.|
||It's been 2 weeks. And... nothing? Really?|
Congratulations. Absolute no reaction at all, except if you "need to" close duplicates.
The overall activity on this bugtracker doesn't promise good things. I can't recommend offensive security for our pen testers...
> The overall activity on this bugtracker doesn't promise good things. I can't recommend offensive security for our pen testers...
There seems to be some misunderstanding about this bugtracker. Here's a a place where you report what you think might be bugs in Kali. If there's something we (Kali developers) can do about it, we answer and discuss the issue. OTOH, if there's nothing we can do about it, or if we think it's not a bug in Kali, then we'll close the bug report.
In this case, I think there's something wrong with your setup. If Kali was universally broken in Hyper-V, this bug report would have turned into an active conversation, with many other users joining and reporting the same issue. But it did not happen, nobody else reported a similar issue. Therefore it seems to be a problem on your side. I recommend that you try https://forums.kali.org/ or the Kali IRC channel. Thanks.
> If Kali was universally broken in Hyper-V
You mean if people were knowing and actually using Hyper-V (Win X Pro only!) instead of VirtualBox, VMware player, or your WSL-Implementation.
> this bug report would have turned into an active conversation
When I opened this report, the overall activity here was at 0000020:0000010 posts every 7 days.
> Therefore it seems to be a problem on your side.
That's why there are steps to reproduce the issue. I "expected" one of you trying this, for confirming or contradicting my report, instead of "probably caused by his setup, let's not respond at all until he finds out on his own".
Talking about my setup: I'm using this system for a very long time now for daily business, without any issues. I even fired up another live distribution for testing and to confirm, the guest integration actually works as expected. I even narrowed it down to being related to the graphical interface. If I'd have had another hyper-v host here, I've would have tested it there as well. Based on 20 years of practical experience, I am pretty sure this is an issue with kali.
There's a communication issue. I'd be ashamed if I leave (potential) customers hanging for more than 2 hours, but that's my standard. A "yes, we got your issue and are investigating" mail after 24, maybe 48 hours is the bare minimum. 6 Weeks of silence...
Thanks for nothing.
Yep we should have answered earlier, that mistake was on us, granted.
This being said, I don't have setup to test Hyper-V. Those who have might just not have the time, not sure, I can ping some people but it's likely going to be "Ok, tried it, no problem on my side". Then we won't have the time and resources to drill down until we find the exact cause of the issue. That's why it's worth also trying to post on https://forums.kali.org/, maybe you'll be more lucky there.
> I'd be ashamed if I leave (potential) customers hanging for more than 2 hours, but that's my standard. A "yes, we got your issue and are investigating" mail after 24, maybe 48 hours is the bare minimum. 6 Weeks of silence...
What customers you're talking about? Kali is open-source, for everyone to use. The bug tracker is not a sales channel, and it's not your paid-for support either. It's true that it's a place where you can reach us (Kali developers), but then that's all, there's no promise for support. Our answers to bug reports are a best effort, we have limited time for it, and many other things to do. Some bug reports just don't receive much attention, don't seem to be actionable on our side, so we have to triage and leave some bugs aside, they will never be fixed here and that's fine. Maybe you came here with different expectations, hope that I clarified that.
From my side as a user / reader:
Choosing a better fitting issue title from the start could have also helped to get more attraction to this issue report ;-)
Changing the following kernel configuration seems to fix the issue:
forget the previous one... try this:
< # CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set
||Sharing the mailing list conversation with insights, why this change is required: https://lore.kernel.org/linux-hyperv/[email protected]od.outlook.com/T/#t|
Thank you for the update.
I've shared it with the rest of the team to discuss about it, as I'm not familiar with this at all
||This tweak should be probably suggested to Debian directly, as we mostly use their kernel configuration|
||This is correct. I hope, MS takes care of that.|
Thanks for the thread discussion. That is quite useful. However in Kali we are following Debian's kernel configuration and Debian's udev package so the changes should be requested to Debian directly.
A bug against "linux" to suggest enabling CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y with the link and rationale would be useful. I see no such request here:
A bug against "systemd" to request the udev rules might also be useful. I don't see any similar bug here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=systemd
I don't know which package ships the udev rules in Ubuntu, but it might be useful to check if we should report this to "systemd" or to some other package. Also a pointer to the desired udev rules might be useful.
Do you have any experience how fast debian fixes such things? Might be worth adding the kernel config here temporarily, you could save me from rebuilding my kernel every time you update.
And I'll probably need the debian version you're building kali on for creating the reports.
||I have uploaded a patched version of linux in kali-experimental|
||Thanks! I'm gonna give it a test later on, will report back.|
|2022-01-29 21:49||max06||New Issue|
|2022-01-29 21:50||max06||Note Added: 0015676|
|2022-02-12 13:15||max06||Note Added: 0015720|
|2022-02-27 21:25||max06||Issue cloned: 0007602|
|2022-02-27 21:25||max06||Relationship added||related to 0007602|
|2022-02-28 07:24||daniruiz||Relationship replaced||has duplicate 0007602|
|2022-03-10 19:59||max06||Note Added: 0015844|
|2022-03-11 02:37||arnaudr||Note Added: 0015845|
|2022-03-13 13:12||max06||Note Added: 0015878|
|2022-03-14 02:48||arnaudr||Note Added: 0015882|
|2022-03-14 22:03||kali-bugreport||Note Added: 0015888|
|2022-03-25 13:50||g0tmi1k||Priority||high => normal|
|2022-03-25 13:57||g0tmi1k||Severity||major => feature|
|2022-03-25 13:58||g0tmi1k||Severity||feature => minor|
|2022-06-11 13:02||max06||Note Added: 0016251|
|2022-06-11 16:03||max06||Note Added: 0016256|
|2022-06-11 21:14||max06||Note Added: 0016262|
|2022-06-15 18:52||daniruiz||Note Added: 0016291|
|2022-06-15 19:31||daniruiz||Note Added: 0016295|
|2022-06-15 19:31||max06||Note Added: 0016296|
|2022-06-15 19:49||rhertzog||Note Added: 0016297|
|2022-06-15 19:59||max06||Note Added: 0016298|
|2022-06-28 11:55||sbrun||Assigned To||=> sbrun|
|2022-06-28 11:55||sbrun||Status||new => assigned|
|2022-06-30 09:48||sbrun||Note Added: 0016341|
|2022-06-30 12:41||max06||Note Added: 0016342|