Repository navigation
feat(zone-kvm): enable TUN in the zone-kvm kernel - #290
Conversation
protect's KVM backend runs cloud-hypervisor, which gives each networked zone a TAP device through /dev/net/tun. Without CONFIG_TUN, protect cannot run its KVM zones inside a zone-kvm zone, which the Edera CI runners need to run protect's E2E suite without a nested rig VM. CONFIG_TUN depends on NETDEVICES and NET_CORE, both already set in zone.config. Refs ENGINFR-116
| CONFIG_KVM_AMD=y | ||
| CONFIG_KVM_INTEL=y | ||
| CONFIG_BLK_DEV_NBD=y | ||
| CONFIG_TUN=y |
There was a problem hiding this comment.
I think we'll wanna add the same to the arm64 zone kernel too, correct?
We don't build it for zone-kvm yet AFAICT but we might as well keep it consistent across both.
There was a problem hiding this comment.
We currently don't run any dogfood runners on ARM (at least not to my knowledge) but if you think it's relatively harmless and something we may want to do down the line, we could.
There was a problem hiding this comment.
Not sure if we want to add the config but not build the kernel for ARM. If that's what you meant, let me know and I'll drop the config.yaml change :)
There was a problem hiding this comment.
I missed we lacked an arm64 fragment for zone-kvm - but yeah, in general we should maintain 1-1 parity, so thanks for adding!
All fragments should have both x86_64 and arm64 variants (where possible) and features should be kept in sync across both archs (where possible).
The aarch64 fragment lists the same options as x86_64's: KVM, NBD and TUN. The arm64 defconfig already enables VIRTUALIZATION, KVM and TUN in the aarch64 zone kernel, so in practice only NBD changes, from a module to built in. Setting them here keeps the flavor from depending on defconfig. Refs ENGINFR-116
Summary
Adds
CONFIG_TUN=ytoconfigs/x86_64/zone-kvm.fragment.config, so zones running thezone-kvmkernel get/dev/net/tun.Why
We're trialling protect's KVM E2E suite directly in an Edera runner zone, without a nested QEMU rig VM, which is too slow at that depth. protect's KVM backend runs cloud-hypervisor, which gives each networked zone a TAP device through
/dev/net/tun. The trial on the Intel runners got as far as device setup and stopped there: no Edera zone kernel has TUN.CONFIG_TUNdepends onNETDEVICESandNET_CORE, whichzone.configalready sets. Theverify-config.pystickiness check will fail the build if it doesn't stick. PR CI doesn't buildzone-kvm, so the first real check is the post-merge build.Refs ENGINFR-116