Wednesday, 2021-04-14

*** khyr0n has quit IRC01:23
*** ailan__ has quit IRC02:16
*** ailan has joined #kata-dev02:25
*** khyr0n has joined #kata-dev03:07
kata-irc-bot<eric.ernst> Was reading through that PR a bit -- thanks for all the work on it Carlos.05:08
kata-irc-bot<eric.ernst> I'm curious how we can handle this correctly: https://github.com/kata-containers/runtime/pull/793/commits/ba0088889912a34d59c3dcbfa204639233fc0806#r26489997605:08
kata-irc-bot<eric.ernst> Otherwise, I could see starting a VM with default memory (2048 MB, let's say, to facilitate being able to hotplug a large container). Once the containers start, we realize that it is just 2 containers with 50 MB each. Let's say we have a reserved memory required for running guest services, 200MB. What I'm curious to see is if we can at that point start up the virtio-balloon to at least make 1748MB (2048MB-100MB-200MB) of memory not05:13
kata-irc-botaccessbile to the guest, and/or if needed reclaim some of that memory back to the host (ie, if it had become mapped already for caches, etc).05:13
kata-irc-bot<eric.ernst> I imagine if we did this for a pod, we'd likely not have much of that memory allocated already, from host perspective, and it'd be more preventative, limiting the amount of cacheing the kernel can do in the guest, and limiting memory usage for an active/longer running pod.05:15
kata-irc-bot<eric.ernst> Curious if you have thoughts on this @bergwolf?05:15
*** egernst_ has quit IRC05:23
*** egernst has joined #kata-dev05:24
kata-irc-bot<bergwolf> maybe we can a static amount + a proportional amount, like xMB + y% of container memory, that should be more accurate than just the static default one05:24
kata-irc-bot<eric.ernst> yes, makes sense to me05:27
kata-irc-bot<eric.ernst> y=mx+b.  What's m? and b? :)05:27
kata-irc-bot<eric.ernst> @samuel.ortiz AFAIU CLH has balloon support as well, correct?05:28
kata-irc-bot<eric.ernst> I think this could be pretty helpful in making us more efficient with memory (though, in a perfect world we'd have all the container sizing info up front and not need hotplug...... )05:29
*** egernst has quit IRC05:30
*** sameo has joined #kata-dev05:48
*** hbrueckner has joined #kata-dev06:33
*** iamweswilson has quit IRC06:35
*** iamweswilson has joined #kata-dev06:36
*** fgiudici has joined #kata-dev06:37
kata-irc-bot<samuel.ortiz> @eric.ernst I'm trying to understand your example here: You'd want virtio-balloon to size the VM memory down to 300 MB through virtio-balloon?06:54
kata-irc-bot<samuel.ortiz> @eric.ernst Yes, CLH has both balloon and virtio-mem support06:55
kata-irc-bot<samuel.ortiz> With an agent inside the guest, there's quite many things we could do, including by-passing the host <-> guest virtio commands for ballooning.07:00
kata-irc-bot<samuel.ortiz> The agent has a very precise view of the memory consumption and usage trend inside, it could autonomously drive ballooning.07:01
*** amorenoz__ has joined #kata-dev07:04
*** Yarboa has quit IRC07:04
*** Yarboa has joined #kata-dev07:07
kata-irc-bot<adeodhar> Does Kata container support live migration of the VM to another node? What are the steps to perform live migration of a Kata container?07:10
*** dklyle has quit IRC07:10
kata-irc-bot<bergwolf> @adeodhar no, it is not supported07:12
kata-irc-bot<adeodhar> any idea if is it planned in the roadmap?07:13
kata-irc-bot<fidencio> @adeodhar not planned, but I'd say it's worth opening an request for enhancement at github.com/kata-containers/kata-containers/ and explain why you see live migration as an important piece for the project07:24
*** egernst has joined #kata-dev07:35
*** jodh has joined #kata-dev07:37
*** sgarzare has joined #kata-dev07:40
*** egernst has quit IRC07:40
*** davidgiluk has joined #kata-dev08:03
*** khyr0n_ has joined #kata-dev08:22
*** khyr0n has quit IRC08:24
*** ricolin has quit IRC08:39
kata-irc-bot<adeodhar> Ok, done - https://github.com/kata-containers/kata-containers/issues/169010:47
kata-irc-bot<fidencio> Thanks, @adeodhar!11:13
*** davidgiluk has quit IRC11:58
*** davidgiluk has joined #kata-dev12:13
*** devimc has joined #kata-dev12:14
*** Yarboa has quit IRC12:25
*** Yarboa has joined #kata-dev12:26
*** sgarzare has quit IRC12:53
*** sgarzare has joined #kata-dev12:53
*** fuentess has joined #kata-dev13:02
*** ricolin has joined #kata-dev13:34
*** khyr0n_ is now known as khyr0n13:40
*** khyr0n has quit IRC13:40
*** khyr0n has joined #kata-dev13:41
*** crobinso has joined #kata-dev13:41
*** egernst has joined #kata-dev13:44
*** egernst has quit IRC13:58
*** egernst has joined #kata-dev13:59
*** sgarzare has quit IRC14:04
*** sgarzare has joined #kata-dev14:07
kata-irc-bot<christophe> Sorry, yes, I did. Forgot to report on kata-dev. Will do that right away.14:44
kata-irc-bot<christophe> Good news, seems to work OK14:44
kata-irc-bot<christophe> Email sent. Sorry, had sent it only internally.14:50
kata-irc-bot<christophe> @eric.ernst Thanks for the reminder ;)14:54
*** dklyle has joined #kata-dev15:09
kata-irc-bot<eric.ernst> Thanks for the info Christophe. Reading through now.15:12
kata-irc-bot<eric.ernst> I guess the main metric is the memory usage in bytes reported in the cgroup (ie, if we are looking at OOM events)15:13
kata-irc-bot<christophe> I'm trying to understand seccomp with agent 2.0. Am I correct in thinking that there is no guest seccomp support with the Rust agent yet, or did I miss it?15:19
kata-irc-bot<christophe> Yes, I think so. What concerned me initially was that I assumed `ps` and `top` were correctly computing the `rss` being displayed. Apparently not, so that led me to drawing an incorrect conclusion at first.15:33
kata-irc-bot<christophe> There is double accounting there, but we don't rely on that, so as long as we propagate cgroup data, we are good.15:34
kata-irc-bot<eric.ernst> Yup -- its being worked on.15:48
kata-irc-bot<eric.ernst> Dev from sony is working on libseccomp crate AFAIU... let me dig up the issue tracking this work.15:49
kata-irc-bot<christophe> Thanks!15:49
kata-irc-bot<eric.ernst> https://github.com/kata-containers/kata-containers/issues/147615:49
kata-irc-bot<eric.ernst> He's hoping EOW.15:49
kata-irc-bot<eric.ernst> I am also eagerly tracking this!15:50
*** sgarzare has quit IRC15:52
*** fgiudici has quit IRC16:17
*** ailan has quit IRC16:51
*** jodh has quit IRC17:02
*** hbrueckner has quit IRC17:32
*** khyr0n_ has joined #kata-dev17:36
*** khyr0n has quit IRC17:37
*** khyr0n_ has quit IRC17:41
*** khyr0n has joined #kata-dev17:41
*** amorenoz__ has quit IRC19:04
*** amorenoz has joined #kata-dev19:10
*** davidgiluk has quit IRC19:15
*** amorenoz has quit IRC19:35
*** amorenoz has joined #kata-dev19:55
*** amorenoz has quit IRC20:07
*** amorenoz has joined #kata-dev20:12
*** amorenoz has quit IRC20:21
*** devimc has quit IRC21:01
*** sameo has quit IRC21:30
*** sameo_ has joined #kata-dev21:30
*** sameo_ has quit IRC22:36
kata-irc-bot<eric.ernst> @samuel.ortiz -- yes, that would be my goal.22:59
kata-irc-bot<eric.ernst> the problem that I foresee is we need a "lot" of memory in place if we were to online memory for a new container starting.23:00
kata-irc-bot<eric.ernst> For example, if we were starting a container with 57GB of RAM as its limit, we'd need to ensure we have 1024GB in the guest.23:01
kata-irc-bot<eric.ernst> (from my testing, it requires about 1MB for every 53MB of memory being onlined with ACPI hotplug in qemu)23:02
kata-irc-bot<jose.carlos.venegas.m> @eric.ernst this is only when you hotplug or even if you start the VM with all that memory on could plug ?23:07
kata-irc-bot<eric.ernst> You'd only have the 1MB per 53MB required for onlining new memory23:07
*** crobinso has quit IRC23:08
*** fuentess has quit IRC23:36
*** irclogbot_2 has quit IRC23:50
*** irclogbot_1 has joined #kata-dev23:55

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!