olivierlambert Current version: 5.106.1

On the XOA page, I enter my email/password in the Registration box.
There's no way to 'unregister' and just use the free version.

XOA knows I have a 'trial' but the license is not activated (because it is active on another XOA VM) and it locks into the XOA page only.

olivierlambert I understand enforcement, but this is now draconian.

As a test:

I deployed XOA from the web. Fine.

But I can't update it without registering it. Fine.

I login with my Vates XOA account, now it says I'm registered and can update. So I update XOA.

Now I'm registered but not licensed and I get the error and can't use XOA Your current Xen Orchestra license has expired (Dec 31, 1969). Please reach out to your vendor.

I try to unregister, but that's not an option. I enter a bad email/password so registration fails, but I still get an error and am restricted.

So, there's no way for me to use and update a "free" XOA without forced registration on to a new account? I could use trial XOA and update without registering before. I could register but not use a XOA license and use the free version before...

Danp Activate license resolved that issue, but this is different than before! Just having the trial license was enough to make everything work without error. So, trials will no long work without activation (may be that how it always should have worked).

michael.manley Thanks for the update! I still use it, mostly for the direct (not web based) console and it can still do a few things XO does not.

The update did not replace the old version (also different install location), but that's ok. I just uninstalled the old one and reconnected to the XCP servers.

Danp Two steps forward, one step back. The update to 5.106.1 worked and XOA is reachable, but not usable...

Now I get the error at the top:
Your current Xen Orchestra license has expired (Dec 31, 1969). Please reach out to your vendor.

But for Registration I have:
You have a Xen Orchestra Appliance granted under trial. Your trial lasts until 12/31/2025, 10:59:31 AM

olivierlambert After upgrading XOA to 5.106.0, now all I see is an error has occurred.

XOA was working, I did the normal self upgrade. XOA runs and after I login, it starts to load the normal page, I see the left side menu show up and then tries to load the normal normal VM running page URL of https://xoa/#/home?p=1&s=power_state%3Arunning+ and then drops to an empty page of an error has occurred. Any XOA page I try to access (including support) ends up dropping out to the same error page. I rebooted the XOA VM and the same issue happens.

NOTE: XO from source (current master 3bb5900, same as release 5.106.0) works correctly.

DustinB The goal is if the primary host is down then XO will connect to another host. If XO connects to a slave host then it will be redirected to the new master but it needs to connect to a working host in the pool.

The idea is to have one entry per pool rather than per host since XO does not need to (or want to) connect to ever host in a pool, but needs to reach one working host per pool.

olivierlambert I'm just one user with an idea... If you found it caused more problems than it solves then maybe it's not a good idea. It's up to your team.

florent No. The dashboard health is clean. No VDIs attached to control domain

Murf You need to upgrade NodeJS to at least version 20.x

Current version is 22.x, so you should just upgrade to that.

When setting up a XCP server in XO, is it possible to enter multiple IPs or host names for a single server entry? If I have a pool of 3 hosts then I can enter the 3 hosts individually and one will work and the others will show an error. I just want just have a single pool server entry with the three IPs (or hostnames) so XO will contact any/all of the a hosts to find a working master from a single entry.

Like: 192.168.1.11, 192.168.1.12, 192.168.1.13

florent I finally got the new code running and I tested a Delta Backup (full first run) with NBD x3 enabled and it's leaving NBD transfer (on xcp1) 99% connected after a run. The backup does complete but the task is stuck.

jasonnix Update to nodejs 22.x. It should be good for a while. Nodejs 24 will be out soon but not required yet.

tjkreidl Interesting that ASRock is also using the NUC name. ASUS also has the new NUC15.

This new ASRock box uses the Ultra 7 255H which has 6P/8E/2LPE cores (no HT).

TeddyAstie I ran iperf3 tests between two VMs on Xeon E5-2680v2 and average results were within 2% of each other with the patch being slower. Peak speed was 14.5 vs. 13.7 Gbits/sec.

2planks Make sure your BIOS settings are correct. Make sure all the virtualization (VTx) and IOMMU (VT-d) features are enabled.

escape222 Yes, using XO.

You can do a quick deploy of XOA as a bootstrap to build your own XO VM.

escape222 I have no problem UEFI booting the same debian-12.10.0-amd64-netinst.iso image on XCP 8.3. I just created a new VM using the Debian 12 template and it worked correctly.

Can you try setting the DVD-drive first in the boot order for the VM (on the Advanced tab). You can disable the network boot too (and also maybe the hard drive as a test).

archw Yes.

cairoti I have had this happen to me.... With HA enabled, when the master fails, a new pool member becomes the new master. With HA enabled and shared storage, designated HA VMs should be restarted on the pool.

If you have stand-alone (per server) storage then VMs on the dead server can't be restarted because their storage is gone.

If you don't have HA enabled then you need to manually force a new master and restart failed VMs.

To force a new master on a pool member use the command xe pool-emergency-transition-to-master from a XCP console. You can't do much to the pool without a master. If your old master just needs to reboot quickly then just do that without changing the pool. If you master is going to be down for a while (more than a few minutes) then pick a new master beforehand, or after as a forced change.

It may take a while to force another pool member to become the new master as the members have to timeout contacting the old dead master.

With a failed master or pool member you have two choices:

1. Kick out the dead host from the pool forever (from the new master). After you fix/replace the dead host you need to REFORMAT and START OVER with a NEW install of XCP (there may be a reset command, not sure). You can then add the NEW host to the existing pool. You CAN NOT re-add a host that has been kicked out from the pool. IF you reformat the dead host and start over with a clean install, you need to kick the old host from the pool as the new server has a new UUID and you can't replace a pool member (just kick old and add new).
2. Don't kick out the dead host and fix the hardware (as long as the drives boot the same XCP data as before). Just turn on the host and it should join the pool and know that it was the master, but there is a new master now and it should just become a normal pool host.

If you fix the old master (and did NOT kick it from the pool) then boot it with the same disks, it should just connect to the pool and know there is a newer master. You can re-designate it as the new master if you wish or just let it be a pool member.

Yes, I have done this (again, just now as a test) with XCP 8.2.1

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.