-
Notifications
You must be signed in to change notification settings - Fork 707
Description
Description
Seeing some different behavior after upgrading to Lima 1.0. When provisioning a machine with socket_vmnet ( installed from source and owned by root ) the VM has two default gateways ( expected ). However the shared interface lima0 now has a lower metric then the bridged interface which prevents the VM from accesses external resources
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.105.1 0.0.0.0 UG 100 0 0 lima0
0.0.0.0 192.168.5.2 0.0.0.0 UG 200 0 0 eth0
192.168.5.0 0.0.0.0 255.255.255.0 U 200 0 0 eth0
192.168.5.2 0.0.0.0 255.255.255.255 UH 200 0 0 eth0
192.168.105.0 0.0.0.0 255.255.255.0 U 100 0 0 lima0
192.168.105.1 0.0.0.0 255.255.255.255 UH 100 0 0 lima0
On the VM created from Lima 1.0 I was able to remove the route for eth0 and recreate it with a lower metric to allow traffic flow externally.
Creating a VM with Lima 0.23.2 also with socket_vmnet ( installed from source and owned by root ), has both default interfaces with the same metric which allows external traffic
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.5.2 0.0.0.0 UG 100 0 0 eth0
0.0.0.0 192.168.105.1 0.0.0.0 UG 100 0 0 lima0
10.42.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
192.168.5.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
192.168.5.2 0.0.0.0 255.255.255.255 UH 100 0 0 eth0
192.168.105.0 0.0.0.0 255.255.255.0 U 100 0 0 lima0
192.168.105.1 0.0.0.0 255.255.255.255 UH 100 0 0 lima0
After chatting with Jan Dubois via Slack it was noted this change comes from #2632
This prevents a scenario where VM need to pull container images from a registry that resides outside the shared network, but access to VM within this shared network are still required.
Eg: K3s using metalLB for BGP to connect to BIRD VMs on the shared network still need to pull container images from a source outside the shared network.