| kata-irc-bot | <gong_ys2004> hi, I have set up one cloud hypervisor kata vm with: `apiVersion: apps/v1` kind: Deployment metadata: name: network-deployment-clh spec: selector: matchLabels: app: network-tool-clh replicas: 1 template: metadata: labels: app: network-tool-clh spec: nodeName: k8s-ovn2 runtimeClassName: kata-clh containers: - name: network-tool image: praqma/network-multitool | 02:40 |
|---|---|---|
| kata-irc-bot | <gong_ys2004> and then get the sandbox id: `ps -ef | grep cloud` root 8944 1636 0 10:41 pts/1 00:00:00 grep --color=auto cloud root 18653 18643 0 10:27 ? 00:00:05 /opt/kata/bin/cloud-hypervisor --api-socket /run/vc/vm/8716a26d87c6f2158374558591804772933511a53dabc9256d4c3f4ddc49a7e2/clh-api.sock | 02:41 |
| kata-irc-bot | <gong_ys2004> and try to login to the vm: `socat stdin unix-connect:clh.sock` CONNECT 1026 | 02:44 |
| kata-irc-bot | <gong_ys2004> the socat exited quickly instead of entering the bash of the vm. | 02:45 |
| kata-irc-bot | <gong_ys2004> the vm’s kernel cmdline is: `# kubectl exec -ti network-deployment-clh-fcc6f5c95-fwq5w -- bash` bash-5.1# cat /proc/cmdline root=/dev/pmem0p1 panic=1 no_timer_check noreplace-smp rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket agent.debug_console_vport=1026 | 02:47 |
| kata-irc-bot | <chongjinheng> thanks for the head up @fidencio! | 03:41 |
| kata-irc-bot | <dgibson> Part of the problem is that "using SR-IOV" can cover several quite different use models, some of which work, some of which don't | 04:30 |
| kata-irc-bot | <dgibson> Many docs on the subject are written with the implicit assumption that the model they're describing is the same as the one the user is trying to do, but without really spelling out what they are | 04:32 |
| kata-irc-bot | <dgibson> I'm pretty concerned about that specific document: it long precedes the code I wrote for what I call "vfio_mode = vfio", which means it's the old-style of vfio support (now referred to as "vfio_mode = guest-kernel") | 04:33 |
| kata-irc-bot | <dgibson> I think that mode is a hideous mess - it doesn't conform to the OCI model and so relies on out of band information to guess what you actually want, and will generally require a workload built specifically for the purpose | 04:34 |
| kata-irc-bot | <dgibson> it does have real use cases with GPUs though | 04:34 |
| kata-irc-bot | <dgibson> I know almost nothing about how docker uses the low-level runtime, so I really don't know what that looks like or how it's going to behave | 04:35 |
| kata-irc-bot | <dgibson> the stuff @fidencio referred to in 2.4 is all about vfio_mode=vfio, so I don't think it will change anything for this case | 04:35 |
| kata-irc-bot | <dgibson> also.. I thought kata didn't support running as a docker runtime any more, so should the doc just be removed entirely? | 04:36 |
| kata-irc-bot | <itskumaresan> Hi Team, Good day to you. I did a performance benchmark with runc vs kata (cloud hypervisor) on requests response time. Kata version: 2.x Container used: nginx Number of requests: 1000 hey tool used to generate requests Found the difference is _*huge*_ and kata seems to perform _*very slow*_ than runc. Outputs are attached. Please check and share your feedback. Thanks | 09:54 |
| kata-irc-bot | <gong_ys2004> so it seems the kata network is bad. are u using tc or macvlan for kata? | 13:55 |
| kata-irc-bot | <eric.ernst> More likely it's dealing with the file system. iirc, the index.html is likely being accessed over virtiofs | 15:14 |
| kata-irc-bot | <eric.ernst> Also, curious if this is baremetal or VM. | 15:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!