It's pointless... It's ridiculous... I LOVE IT!

I think you are not doing yourself justice. Your lesson seems to be that going bare bones again is more hassle than it is worth. otherwise you might have done it already :slight_smile:

I am a virt fan boy ever since I found out it works a charm in my use case. If only we had more/better usb wifi options.

and if I might ask. what CPU type do you set your VM to? I found that most cause weird issues on my platform but when going host (amd ryzen) then all seemed bliss.

I have it set as host as well.

1 Like

It's mostly a bootstrapping issue, a fair weather technology (unless you go full HA/ enterprise with failover et al).
These days you get into real problems if basic internet access fails (NTP is a nice sub-topic here as well), so if there's anything with the hypervisor, you lack then means to fix it (or just read up on documentation) without internet access. It's also a layering violation, you pass interfaces from the hypervisor into the VM, just to get the LAN side out again and give the hypervisor 'internet'. Things can be so easy with a bare iron OpenWrt installation, one cable in (wan), one cable out - should there be any issues, put your old (underpowered, but working OpenWrt platic router into its place until you've fixed it), no sudden interoperability issues with the hypervisor, fewer moving pieces (and all in one place, where it belongs, on the router, rather than potentially conflicting configurations on hypervisor and VM) - easier to grasp in its entirety and a narrower attack surface (better security).

It's not that you can't do it, nor that OpenWrt would have problems with virtualization (other than containerization!), it's a question of reliability, simplicity, robustness and security. A router must always work, 24/7, during software upgrades (keep in mind, you hypervisor needs upgrading too, at a different cadence), it needs kind of direct hardware access (network cards) and it needs to be correctly configured and actively secured, which is easier with less parts moving into (potentially) different directions.

4 Likes

as soon there a coreboot, risc-v board out there, that also has the rest of the bells and whistles then I will challenge you on this aspect :slight_smile:

I no longer trust much of the intel/amd/arm/broadcom/what have we stuff these days. I might be becoming paranoid :frowning:

Just because you’re paranoid, doesn’t mean we aren’t out to get you. :wink:

Some of those bugs are downright ugly. Having watched professional “white hat” hackers at work, you’re correct to have some level of concern.

While we agree for the most part, I think virtualization of OpenWRT can fall under this as well. Pass two interfaces into the OpenWRT container, Internet and LAN and you can still use that old hardware OpenWRT device in an emergency. Of course if you decide to add additional interfaces and route to other containers without first exiting, you might have limited or no functionality for them until all repairs are made.

You've got issues with closed BIOSes, but you have zero issues being on internet..... interesting.

Remember there's (or at least used to be) a Minix instance inside every Intel CPU.

A Risc-V architecture on its own wouldn’t guarantee that the CPU itself has no backdoors. You also have to trust the chip vendor and founder.

1 Like

Well. there you go. One can still access the (visualized) router when things go haywire by IPMI.
Give the host a few kicks and get things running.
This to me feels better than having to go dig deep into your technical room and attach some serial cables or what has one.

But I must admit. In order for this to work there is always some kind of dedicated router there that sits waiting silently for this scenario to happen.

hmm wow. I think I have gone full circle now. Now no longer sure of my own point.

just a heads up, the kmods required by these aren't available in OpenWRT (at least not in 24.10).
it needs the qede module, which depends on the qed module.