Unikernel instances have the loopback interface down, so a workload can't connect to itself on localhost #628

On the unikernel runtime the lo interface is down and has no address, so a workload cannot connect to itself on 127.0.0.1 or ::1. The same workload on Kata has a working loopback. Anything that talks to its own port on localhost (health checks against itself, sidecar-style helpers in one process, sanity self-calls, many frameworks' startup checks) times out on unikernel and works on Kata.

Reproduce

• Image that prints ip addr and ip -6 route in a loop (ghcr.io/mdobush/compute-echo-server:kata-debug-probe-1 and :unikernel-debug-probe-1), and a Node app that listens on [::]:3000 and fetches http://[::1]:3000/ping from inside itself (kata-fetch-probe-1 and unikernel-fetch-probe-1)
• Two workloads per image in production project personal-project-e6d8d69e, 1 instance each in us-central-1, same default network: one general-purpose (Kata), one unikernel
• Read the output with datumctl compute logs <workload>

Kata (ip addr)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host noprefixroute
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 ...

Unikernel (ip addr)

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...

No 127.0.0.1, no ::1, and lo is not UP.

Effect: the Node app's self-fetch to http://[::1]:3000/ping returns 200 in 1 to 2 ms on Kata. On unikernel it times out every time (7 of 7 in the logs), while the same app answers /ping from outside through the ALB.

Also different: eth0 has MTU 1500 on unikernel and 1440 on Kata (the network's MTU is 1440).

Expected: lo is up with 127.0.0.1/8 and ::1/128 on unikernel, like Kata.