When the netvm property of the unikernel is updated and the IP address of the netvm is different, it should work (with the creation of a dedicated virtual interface). When the netvm is force-restarted, the unikernel doesn’t detect that, and doesn’t recreate the virtual interface leading to communication hanging. Even updating the netvm property fails as the netvm’s IP address is unchanged.
If your observations are different, please report and I’ll investigate.
On the bandwidth side, I fully agree, and the path to fix that is long
It’s rare. Mostly they only need a reboot in the deterministic case @palainp describes . Then, 2 or 3 times over the last year I notice my LAN transfer speed has become very slow, and a reboot of the mirage firewall in front of my sys-net-lan fixes it. I haven’t investigated or reported it but next time it happens I will take a close look.
I’ve read that somewhere before. But what does that actually mean?
If you have a 100 Mbit/s connection, does that mean only 80 Mbit/s gets through the Mirage firewall?
Or does the Mirage firewall require 4 CPU cores instead of 2?
Thanks @queen and @unman for bringing this topic up. I used this to test Mirage to see if I’d run again into issues that make it unusable for me. And I immediately ran again into two:
low throughput
it stops working when the corresponding netvm is detached and reattached (because I need to reboot the netvm, in order to apply an update for example).
any hints or workaround from anyone?
maybe I should add: I love the idea of a unikernel firewall. It just makes a lot of sense.
For throughput, try increasing the memory assignment:
For the netvm issue I just use a custom qvm-restart script that I run as needed. The boot is so fast and I see no reason not to restart them frequently. Maybe you could wrap Qubes Update / qubes-vm-update to automate this step after an update. Maybe these tools would benefit from a formal hook script mechanism.
Hear, hear. It’s just a matter of habit, i.e. getting used to restart the Mirage firewall(s) after every update. Or, as @Euwiiwueir writes, have scripts do this for you.
still need to benchmark the memory and nat table changes, but the modifications to my netvm reboot script work - not very elegant, but a decent workaround.
. Then, 2 or 3 times over the last year I notice my LAN transfer speed has become very slow, and a reboot of the mirage firewall in front of my sys-net-lan fixes it. I haven’t investigated or reported it but next time it happens I will take a close look.