Now try running that XCP-ng on something like a Framework 13 Gen 2 board (with an Alder Lake), a Lenovo EliteDesk m75q gen 2 (with a Ryzen 5650) or an XPS15 9750 (Intel iGPU and nVidia GeForce GTX1050M) what I usually use to prototype hypervisors), and you'll find yourself run into multiple issues. Let's start with not having it freak out if it's on the Alder Lake FW13 gen 3 board (probably more of a Framework firmware issue, but seems okay for Proxmox and ESXi 6), or it crashes on the 8.2 installer on the m75q-2 (not sure if it's a hardware thing, but I didn't see that on Proxmox or ESXi 6), or I need to use at least 2 nightly ISOs in order for the VGA console on the XPS15 to even show up. I also had to deal with Secureboot not being a thing on their installer ISOs until relatively recently.
It also doesn't like having a USB NIC (configured as an admin interface) come up correctly on reboots without manual intervention (which is pretty important since you can't administer it if it keeps spawning as a new NIC instead of realizing it's the same NIC...or reordering the NICs so the admin interface comes up somewhere else). I mean, yeah, it's dom0, but it's also the admin entry point for the virtualization node. I have to manually put in an init.d rule on the dom0 image to make the device assignment persist. If this is an environment where I expect others to follow-up, I'll have to make sure that this quirk is documented somewhere and this setting is saved somewhere...it's not something that I need to do out of the box on ESXi 6 or Proxmox.
Oh yeah, and unlike XCP-ng or XenServer, you don't need to run an orchestration VM on the hypervisor to administer the resources attached.
Is that still a thing? If dom0 doesn't even come up correctly with the network settings, how useful is that orchestration VM?
Also, what's the use-case for being able to admin multiple non-related hypervisors under the same roof for a non-production setup, anyways?
Last edited:
