@ItsAlwaysDNS I still have some old Debian systems running just fine. XCP 8.2.1, HVM, Debian 7, upgraded kernel 3.16 (32 bit). They were cloned from hardware systems and just added the XCP agent. I have run even older systems (same age as CentOS 6) and they work correctly.
You can look at this old CentOS 6 post.
@bradmbreer You only need to connect to the pool master. XO will find the other hosts in the pool. If you connect to a non-master, XO will be redirected to the master. If you connect to other hosts in the pool (after the master) it will just give an error. Just ignore the error connecting to other hosts in the same pool.
@olivierlambert I have also run into a different problem. When I start a rolling pool update and I want to make things move faster I'll also manually migrate VMs off of a server that is pending a reboot. The problem is XO will then also migrate the already moved VMs to a new different server. The process should check if the next VM to be migrated is actually still on the server to be rebooted, if not then it should know the VM has already been migrated off (for some reason) and not migrate it again for no reason.
It would also be nice to have a dynamic number of VMs to concurrently migrate. If the VMs are not busy and will be easy to migrate (ie, low active CPU and memory) then it should migrate more concurrently. And/or have a manual selection when you click the pool update button (dynamic/all/some #).
@TS79 @ph7 @JamfoFL
For everyone's future reference: Here is a great XO install video thanks to @lawrencesystems . Also, read the XO from source install docs.
Remember, XO is open-source, so you are the beta tester. If you don't want to do that then Deploy XOA which has been tested and is supported.
If you have no idea what you are doing, just use XOA. Just click on Deploy XOA and follow the prompts. You'll be ready to go in minutes without any deep knowledge or google rabbit hole searches!
@JamfoFL I don't know exactly what you have been doing, but yes, you would normally rebuild after pulling in a new commit. I use the XenOrchestraInstallerUpdater update script by @ronivay . You don't have to update on every commit. You can just wait for the full release update that looks like feat: release 5.103.1
@JamfoFL I use an update script, and yes, it builds a new version after a git pull.
@JamfoFL I am running both XOA and XO source.
For the XOA I just use the Vates update. I don't do any changes to the OS. Don't mess with their packages, just use the update button.
For XO source, I update Node and the OS and rebuild XO for source updates.
@JamfoFL I have only current Node installed. After upgrading Node I rebuilt XO.
@JamfoFL I'm running Node 22 now. I was running 20 before without any problems. Node 18 was a long time ago...
@Mefosheez @anthonyper If it solves the problem, then great!
You can't set or change HAP, it's what the CPU chip supports. I was looking at the notes for the change and part of it is related to hosts that have small HAP sizes (ie, 4K, 2M, not 1G). As there are other updates in the same version the issues must have been fixed by a different part of the patch.
@Mefosheez Does your host not have large HAP size?
Please show the output from xl dmesg | grep HAP on your XCP host.
@olivierlambert @payback007 @flakpyro I tested my Win11 23H2 setup (on XCP 8.3) and had the same type of problem. Everything was updated and working on 23H2 with XenTools 9.4. Then Windows update ran and downloaded 24H2 and just got stuck after a reboot (windows logo and spinning circle). Force reboot made Win11 revert, so that good.
I un-installed the XenTools 9.4 (just from the control panel/uninstall) and then ran windows update again. This time it did update with a few automatic reboots. I then re-installed the XenTools 9.4 and everything is working on Win11 24H2 now.
I guess there is some problem between XenTools 9.4 and 24H2 update, not a XCP problem.
I did not test the ISO 24H2 update, just the automatic windows update.
@ringochan It is "secure", it's using HTTPS. Because it is using a self-signed certificate the browser shows "not secure".
@PGibson It could be the format of the drives on the SAS port and then moved to the SATA port. If the hardware is now "good" you might want to reinstall and start over with the new configuration.
@DustinB The answer is yes, you can, I have.
I have changed modern Linux form BIOS to boot as UEFI. All I had to do was change to GPT, add a ESP/EFI boot partition, change the OS partition mounting, and install the needed EFI boot files. Also update the OS to know it's now a EFI boot setup so the OS updates boot files correctly (a GRUB package change). Then I can set the VM to be UEFI boot... It was not an automated process and I did it as an off-line procedure (not booting the OS I was changing).
UEFI VMs boot quicker than BIOS VMs.
I have not converted windows as I normally started newer versions as UEFI and older version work better with BIOS.
@jgdub Thanks for the update!
You could try reflashing the card, but intel does not make it easy.
@Cygace XO is not directly tied to XCP. So the versions have nothing to do with each other.
You can look at the XO master commits and pick one that lists feat: release 5.xxx.x and that will line up with a XOA release. You can pick a version that is the same as the current XOA release and it will be the same tested base code.
@aprado The onboard "serial port" is not a PCI device. You could try adding a USB serial port or a PCIe card with a serial port.
@PGibson You see the GUI on the VM console because that's the way you installed Debian. If you don't install a GUI or just disable it then you will have just a simple VGA text console. This might help.