This message was deleted.
# rancher-desktop
a
This message was deleted.
f
The best diagram I have is this one from our KubeCon talk. Not sure if that answers your questions:
It shows the old
vde_vmnet
networking, but
socket_vmnet
works the same way. It only shows QEMU networking, not VZ
e
awesome! I use VZ, but is QEMU the better option again after the new updates to be native?
I only use VZ cause it works 🤷 no actual technical reason
f
Some people find VZ to be faster. I sometimes get network timeouts when pulling large images on VZ, but not on QEMU. We have not yet figured out why. If we can fix this, then we may make VZ the default.
e
Ahhh right, I did see your comment on a github issue in regards to that. Thats why I moved. Cool! I'm assuming networking is the same for VZ atleast to get into the shared network?
since I have been able to successfully use
sudo route -n add 10.43.0.0/16 192.168.205.1
to have all service FQDN requests route to the lima VM network
f
Similar. With VZ we are using
vzNAT
for the networking, which doesn't require
root
to run the daemon. The shared and bridged networking solutions require a vmnet daemon that needs to run as
root
.
With QEMU you can only use port forwarding unless you run daemons as
root
. Which for most users is good enough.
e
yeup I give rancher admin access, been using this config lately:
Copy code
start \
        --application.admin-access \
        --application.auto-start \
        --application.path-management-strategy rcfiles \
        --application.start-in-background \
        --container-engine.name docker \
        --experimental.virtual-machine.mount.type virtiofs \
        --experimental.virtual-machine.type vz \
        --experimental.virtual-machine.use-rosetta \
        --kubernetes.enabled \
        --kubernetes.options.traefik \
        --kubernetes.version 1.28.1 \
        --port-forwarding.include-kubernetes-services \
        --virtual-machine.memory-in-gb 12 \
        --virtual-machine.number-cpus 4
the only reason I need in cluster service access is when I debug a program locally but still need access to other services to mimic as if it was running in the cluster
something like
redis.default.svc.cluster.local
f
There is unfortunately no API way to control this, but you can use the
Port Forwarding
page to forward a service to the host.
It should be possible to do this using
kubectl proxy
, but I can't remember anything about it 🙂
e
well I meant the shared network is created since I give admin access and I can access kube resources at the gateway ip of
192.168.205.1
f
Yeah, I was talking about workarounds of you can't use the shared network because you can't use
sudo
e
ah gotcha, understood and I also tried looking at kubectl proxy haha, will still require more reading. I appreciate your time sir! Even your comments on github issues have been helping me!