VMware Cloud Community
ronlaws86
Contributor
Contributor

My thoughts so far!

Hi! sorry this isn't really a question more than a blurb on my thoughts and findings! 

First off, I've used ESXi a lot in a work environment on X86 hardware, so i'm very familiar with the platform and how to use it so with that out of the way: 

I'm absolutely loving having it running on a Pi4, I own 2 here at home and having a low cost, low power consumption device i can spin up Virtual Machines on is an absolute boon for doing homelab stuff and generally running software services like plex as a working example, Unifi network portal, nginx rtmp for streaming and other such software on a tight budget with a tight power bill budget!

I have to say that so far, ESXi Arm has been rock solid in terms of stability - in contrast to running a Pi as a 24/7 device from an SD card, i'd often have issues with SD Cards failing or filling up over time, crashes sometime were common on PIs that had been running for a long time in the background too, but as virtual machines running from a SSD connected to USB3, or running off a iSCSI LUN from a NAS have actually been extremely well behaved and very stable! 

So i'm super happy to report that this solution and method of running software on a Pi 4 is quite viable even for general purpose tasks that perhaps you want to have running on a network but don't want to throw a huge x86 server at. 

Performance wise it is also actually quite decent, of course the Pi4 is small fry compared to other solutions out there, but if you are willing to put a bit of thought in to the images you use on it, you can manage tight resources for your applications quite well and even be surprised how many VMs you can throw on a single pi before seeing noticeable performance degradation. 

Some suggestions I would throw out there are: 
(of course) Alpine Linux if your software stack is reasonably available on this micro distribution. very low memory consumption and overhead leaving more resource for your application stack 

Second place is plain old Debian Linux, which is also very slim, though not as slim as Alpine, will still fire up in around 10 seconds or less from a good SSD on USB3

Third of course is Ubuntu, though Ubuntu consumes a fair amount of ram and if space and overhead are a real factor, I would stay stick with one of the above options unless you have a compelling reason or a requirement to run ubuntu specifically. 

Other random things i've also tried are OpwnWRT, which worked quite well, though I encountered a kernel bug within OpenWRT that made OpenSSL (OpenVPN) crash the kernel in the VM (Though not on the host gladly!) 

All in all, coupled with the other capabilities of the platform, really turn the Pi in to a very powerful and versatile device if your needs fit within a headless host requirements. 

Fingers crossed over time more stuff is available like pfsense 😉 Windows 10 we know is in the works from Microsoft, or Windows server.  

I'm really hoping esxi Arm fling is here to stay as i feel even on a Pi it has a lot of valid use cases where power budgets are a concern or the task needed just does not command many resources, but does require reliability!

2 Replies
cyprienlaplace
VMware Employee
VMware Employee

Hi Ron (I suppose),

Thank you very much for your comment! We like to help people with their issues, but we also like people sharing the good experiences 🙂

I see that you have been testing OpenWRT in Arm VMs. I had a look some time back, but I couldn't find any installer/image that would work for a VM. I will be very interested if you can quickly explain how you did it.

Cheers,
Cyprien

Reply
0 Kudos
ronlaws86
Contributor
Contributor

Ron is correct! 

For Open WRT I used this Image which Statto99 over on the OpenWRT Forum has put together for testing, though like I mentioned, OpenVPN seems to cause the kernel to panic, so it's only really useful for standard networking and routing. (Which is the core purpose anyway)

https://forum.openwrt.org/t/arm-fling-installation/83740

I've attached the file as well in case of link rot in the future.