You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+71Lines changed: 71 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -91,6 +91,7 @@ RunCVM features:
91
91
-[Installation](#installation)
92
92
-[Upgrading](#upgrading)
93
93
-[Features and Limitations](#features-and-limitations)
94
+
-[RunCVM vs Kata comparison](#runcvm-vs-kata-comparison)
94
95
-[Kernel selection](#kernel-selection)
95
96
-[Option reference](#option-reference)
96
97
-[Advanced usage](#advanced-usage)
@@ -242,6 +243,76 @@ In the below summary of RunCVM's current main features and limitations, [+] is u
242
243
-[+] Use any kernel, either one pre-packaged with RunCVM or roll your own
243
244
-[+] RunCVM will try to select an appropriate kernel to use based on examination of `/etc/os-release` within the image being launched.
244
245
246
+
## RunCVM vs Kata comparison
247
+
248
+
This table provides a high-level comparison of RunCVM and Kata across various features like kernels, networking/DNS, memory allocation, namespace handling, method of operation, and performance characteristics:
249
+
250
+
| Feature | RunCVM | Kata |
251
+
|---------|--------|------|
252
+
|**Methodology**| Boots VM from distribution kernels with container's filesystem directly mounted as root filesystem, using virtiofs. VM setup code and kernel modules are bind-mounted into the container. VM's PID1 runs setup code to reproduce the container's networking environment within the VM before executing the container's original entrypoint. | Boots VM from custom kernel with custom root disk image, mounts the virtiofsd-shared host container filesystem to a target folder and executes the container's entrypoint within a restricted namespace having chrooted to that folder. |
253
+
|**Privileges/restrictions**| Container code has full root access to VM and its devices. It may run anything that runs in a VM, mounting filesystems, installing kernel modules, accessing devices. RunCVM helper processes are visible to `ps` etc. | Runs container code inside a VM namespace with restricted privileges. Use of mounts, kernel modules is restricted. Kata helper processes (like kata-agent and chronyd) are invisible to `ps`.|
254
+
|**Kernels**| Launches stock Alpine, Debian, Ubuntu kernels. Kernel `/lib/modules` automatically mounted within VM. Install any needed modules without host reconfiguration. | Launches custom kernels. Kernel modules aren't mounted and need host reconfiguration to be installed. |
255
+
|**Networking/DNS**| Docker container networking + internal/external DNS out-of-the-box. No support for `docker network connect/disconnect`| DNS issues presented: with custom network, external ping works, but DNS lookups fail both for internal docker hosts and external hosts.[^1]|
256
+
|**Memory**| VM assigned and reports total memory as per `--memory <mem>`| VM total memory reported by `free` appears unrelated to `--memory <mem>` specified [^2]|
257
+
|**CPUs**| VM assigned and reports CPUs as per `--cpus <cpus>`| CPUs must be hardcoded in Kata host config |
258
+
|**Performance**|| Custom kernel optimisations may deliver improved startup (~3.2s) or operational performance (~15%) |
259
+
|**virtiofsd**| Runs `virtiofsd` in container namespace | Unknown |
260
+
261
+
[^1]: `docker network create --scope=local testnet >/dev/null && docker run --name=test --rm --runtime=kata --network=testnet --entrypoint=/bin/ash alpine -c 'for n in test google.com 8.8.8.8; do echo "ping $n ..."; ping -q -c 8 -i 0.5 $n; done'; docker network rm testnet >/dev/null` succeeds on `runc` and `runcvm` but at time of writing (2023-12-31) the DNS lookups needed fail on `kata`.
262
+
263
+
```
264
+
$ docker network create --scope=local testnet >/dev/null && docker run --name=test --rm -it --runtime=kata --network=testnet --entrypoint=/bin/ash alpine -c 'for n in test google.com 8.8.8.8; do echo "ping $n ..."; ping -q -c 8 -i 0.5 $n; done'; docker network rm testnet >/dev/null
265
+
ping test ...
266
+
ping: bad address 'test'
267
+
ping google.com ...
268
+
ping: bad address 'google.com'
269
+
ping 8.8.8.8 ...
270
+
PING 8.8.8.8 (8.8.8.8): 56 data bytes
271
+
272
+
--- 8.8.8.8 ping statistics ---
273
+
8 packets transmitted, 8 packets received, 0% packet loss
274
+
round-trip min/avg/max = 0.911/1.716/3.123 ms
275
+
```
276
+
277
+
```
278
+
$ docker network create --scope=local testnet >/dev/null && docker run --name=test --rm -it --runtime=runcvm --network=testnet --entrypoint=/bin/ash alpine -c 'for n in test google.com 8.8.8.8; do echo "ping $n ..."; ping -q -c 8 -i 0.5 $n; done'; docker network rm testnet >/dev/null
279
+
ping test ...
280
+
PING test (172.25.8.2): 56 data bytes
281
+
282
+
--- test ping statistics ---
283
+
8 packets transmitted, 8 packets received, 0% packet loss
284
+
round-trip min/avg/max = 0.033/0.085/0.137 ms
285
+
ping google.com ...
286
+
PING google.com (172.217.16.238): 56 data bytes
287
+
288
+
--- google.com ping statistics ---
289
+
8 packets transmitted, 8 packets received, 0% packet loss
290
+
round-trip min/avg/max = 8.221/8.398/9.017 ms
291
+
ping 8.8.8.8 ...
292
+
PING 8.8.8.8 (8.8.8.8): 56 data bytes
293
+
294
+
--- 8.8.8.8 ping statistics ---
295
+
8 packets transmitted, 8 packets received, 0% packet loss
When creating a container, RunCVM will examine the image being launched to try to determine a suitable kernel to boot the VM with. Its process is as follows:
0 commit comments