OpenNebula Community Edition as a cloud management front-end, with the Sunstone web console, the full one* CLI toolset and the XML-RPC API running the moment the instance boots.
OpenNebula is an open source platform for building and running private clouds and managed virtual infrastructure. It holds the model of an entire estate, virtual machines, virtual networks, images, templates, users, groups and quotas, and schedules workloads onto the hypervisor capacity registered with it. You drive it from the Sunstone web console, a complete command line toolset, or an XML-RPC API.
This image is an OpenNebula front-end, or management node: the control plane. It runs the oned core daemon, the scheduler, the FireEdge Sunstone web console, OneFlow and OneGate. It is not a hypervisor host and does not run virtual machines itself. OpenNebula packages the two roles separately upstream, and the hypervisor packages, opennebula-node-kvm and opennebula-node-lxc, are deliberately not installed here, because the general purpose virtual machine sizes this image is validated on do not offer nested virtualisation. Rather than appear to be a self contained hypervisor and then fail the first time a workload is started, the image is an honest, fully functional control plane, and the guide covers exactly what to attach to it: you register your own KVM or LXC hosts with onehost create, which is the standard OpenNebula topology for any deployment beyond a single laptop.
It suits teams who want a managed OpenNebula control plane for hypervisor capacity they already have or intend to provision, whether that is on-premises servers, bare metal in a colocation facility, or dedicated hosts.
Upstream, OpenNebula generates its oneadmin password when the package is installed and creates its internal serveradmin account the first time the daemon starts. In a shared machine image both of those, plus the console's session signing key and the front-end's SSH private key, would be baked in at build time and would be identical on every instance, so every customer would hold the keys to every other customer's cloud controller. This image never ships any of them. The build removes the bootstrapped database, every credential file, the console session key and the build-time SSH keypair, and closes a systemd condition gate so the daemon physically cannot start without them. On the first boot of each instance a unique administrator password, a unique internal server password, a fresh console signing key and a fresh SSH keypair are generated, and the database is bootstrapped with the new password, so the build-time credential exists nowhere in the image at all. The XML-RPC API is bound to loopback so the control plane is not exposed to the internet unless you deliberately open it, and the authenticated web console is the only public listener. Every image is proven rather than assumed, with an authenticated control plane round trip that creates a virtual network, reads back the exact values it set, confirms it in the pool listing and deletes it, plus a negative control that confirms a wrong password is refused on both the CLI and the raw API. Every deployment comes with a paired deploy guide and 24/7 cloudimg support.
Real screenshots taken while testing this image against its deployment guide.