Xen Project officially ports its hypervisor to Raspberry Pi 4 The Xen Project has ported its hypervisor to the 64-bit Raspberry Pi 4. The idea to do an official port bubbled up from the Xen community and then reached the desk of George Dunlap, chairman of the Xen Project’s Advisory Board. Dunlap mentioned the idea to an acquaintance who works at the Raspberry Pi Foundation, and was told …
I personally think the best version is the Zero W followed by the 3b+
I have the 3b running pihole DNS, mysql and apache for home monitoring temps etc. The zero is in the garden solar powered with a 12v battery and controls the water feature (it's not a pond, I'm lot allowed one of them :) pumps and heaters to keep the fishies happy. It was fun setting it all up for under £100, kept me occupied for several days while on furlough:)
I was provided a dual Pentium II 233MHz machine with 256MB RAM and 10GB Hard drive on Windows NT4 which at the time was the most powerful machine the corporation could provide.
This brought the compile time for a CD ROM based manual down from 14 hours to 3 hours.
I then found the bit of code which was making it slow which made it do the job in 10 minutes!
A PI linked to a decent storage drive would definitely run that compile. However I don't think it would work well to an SD card.
A good evolution given where the CPU market seems to be heading and "cool points" for the developers for pulling this off.
However, with a cupboard full of different PI versions since they first came out and several stuck with Velcro to different things around the house, I can't see a need to virtualise them as its often the form factor, options for physical placement and access to the various ports that is most important.
If the memory capacity keeps increasing, then I might change my mind, but I'd expect that most would probably want to containerise rather than virtualise and docker has been on them for a long time now. IO rates to the SD card will also be a problem, so I guess definitely a Pi4 only solution where USB3 exits
There are a couple of areas where I expect this will be extended in the coming months.
1. A virtualised ARM based mobile phone, one virtual one for the way through the airport and one the real one for when you get there.
2. Some form of malware / rootkit that uses the new virtualisation as this always seems to follow such evolutions.
Once you have a ... murder, shoal, ... mob ...??? ... of feisty PI's around the house, then you gotta manage them. Hopefully with something like Puppet or CFEngine. That tool will need a server.
Probably one also needs an apt-cache, like apt-cacher-ng. Which, for simplicity, is Another server.
Those would fit neatly into a PI-4, especially when virtualised. In my experience, management tools tend to be quirky and some of them (CFEngine?) are even installed from a shell-script rather than a package, creating "a mess" from the start on a packetized system. This way we can keep the mess in a container.
@Fajensen
Nah, that's where a good Internet connection, a couple of cron scripts and a NAS comes in. Use the right tools for the job and keep it simple. Puppet and the like is not require
Most of the builds are for specific tasks (Kodi, Asterisk, VPN, some home automation, etc) and hence already packaged up by the providers or me and there is no ongoing platform management via some form of DSC tool, they just use their own UI / cmd line once to get the base config and then never need to fiddle again. This is why I said no need for virtual Pi
Just thinking more on this, it a Pi container called a bowl or a lunchbox ?
The SD card is a big problem, those things are horrible. OK as a floppy drive but terrible as a hard drive. I think Xen on ARM is the goal here for the server market but Xen on PI is very cool. If you want performance then Docker or LXC containers is the way to virtualize. It's just that it's easier for the user if they get a whole virtual PI rather than have to use a container.
Maybe some people just prefer the Xen UI?
It's objectively better if there is more than one option, it pushes both projects to improve.
It also sounds like the Linux kernel previously didn't support some of the things needed for full virtualization (eg of DMA) on some types of hardware.
Perhaps KVM will now also be improved because it won't have to use slower workarounds?
Xen never got upstreamed into the Linux kernel because it’s bloated. It has it’s own memory management, scheduler, IPC model, and so forth.
It turns out that what starts as “a minimal hypervisor” very quickly becomes an entire Kernel of its own. There are other projects that seem to suffer the same fate (Grub and BusyBox spring to mind).
KVM solves this problem by just treating a VM as a Linux process with a funny ABI.
Sometimes the choice is just wrong, unfortunately. Maybe there is something useful in here, but I doubt there’s anything KVM couldn’t already do...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
