@stormi The new installer boots fine on my systems. I was able to update my hosts from 8.2.1 to 8.3. Huzzah!

Thanks for all the hard work!

@bleader

Hopefully the palm print on my forehead isn't visible from where you are sitting.

Of course the interface needs an IP address.

In my defense, normally for something like this, I wouldn't put it on the bonded interface with all the trunked VLAN's for guest traffic (we don't give that one an IP) and it would go on the other bonded interface that isn't trunked and does get an IP, but these are test hosts and I didn't set up the other bond, so it is pulling double duty.

I was able to set the IP's and get SDN working.

Thanks!

@stormi said in XCP-ng 8.3 and Dell R660 - crash during boot, halts remainder of installer process (bnxt_en?):

Hi! We have an updated installer for you in https://xcp-ng.org/blog/2025/12/18/december-2025-security-and-maintenance-updates-for-xcp-ng-8-3-lts/ !

If I am reading it right, the link is to the 20250606 installer. Have you replaced the 20250606 iso with an updated one with the same June date in the name or did you intend to link a 20251218 iso?

@bleader

Hopefully the palm print on my forehead isn't visible from where you are sitting.

Of course the interface needs an IP address.

In my defense, normally for something like this, I wouldn't put it on the bonded interface with all the trunked VLAN's for guest traffic (we don't give that one an IP) and it would go on the other bonded interface that isn't trunked and does get an IP, but these are test hosts and I didn't set up the other bond, so it is pulling double duty.

I was able to set the IP's and get SDN working.

Thanks!

Greetings,

I'm trying to test out the SDN feature during my trial. I have 2 hosts set up the same with 3 connected interfaces each. One 1G interface where Management is and two 25G interfaces that I created a bond at the Pool level. The bond is working fine for my guests.

When I create a new network, if I immediately select the interface dropdown, I see bond0 as an option. If I choose the Private Network toggle, the only option available for interface is eth0, the 1G interface.

Is this expected behavior? Why wouldn't the bond be an available option?

If this is not expected, the one weirdness that I can think of is that I initially created this cluster on XO and set up the bond. I then wanted to play with XOA and imported the cluster. So, maybe there is some weirdness there and I need to remove and recreate the bond interface to get XOA to properly see it.

Any other ideas?

Thanks!

Greetings!

Rolling Updates Failed 3x for me this morning. I was attempting to apply updates announced here:

https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/350

I didn't want to clutter that thread as my case may just be related to how my test system is set up.

Setup:
2x Hosts (up to date prior to the release this morning)
XOA - up to date on Latest channel, Premium Trial active
I have 2 FC attached, multipath SR's where my VDI's live
My ISO store is an SR on local storage on one of my Hosts (the Master)

Related Question: why can't I create an ISO store on FC SAN disk? It looks like NFS/SMB/Local are the only options.

First Attempt at Rolling Pool Update:

• Failed immediately, unable to evac Master Host
• The failure was mostly silent. There was a raw log in Tasks that wasn't very useful (to me anyways) that it cannot evac host.
• I believe this was due to my testing Self-Service yesterday, I created 3 VM's and attached a RHEL ISO and booted into the installer. Since I was just testing the ability to create VM's and permissions, I left them in this state. Since the ISO SR is attached to this Host, I am not surprised that the migration failed, but it seems like the Rolling Update should have been able to detect this before starting.
• I was able to Migrate these 3 VM's manually without unmounting the ISO. I didn't look before migrating, but the ISO is no longer mounted after the migrations.

Second Attempt:

• Master Host evac proceeded, but failed to migrate 2 VM's after 17min. It looks like I left Guest Tools ISO mounted on these.
• Unmounted tools and did not Migrate VM's, but proceeded to attempt 3

Third Attempt:

• Master Host completed the evac of the last 2 VM's, applied updates and rebooted. Yay!
• After the Host came back up, Host2 evac started immediately
• Evac eventually failed on 2 VM's. One was one of the VM's that had the RHEL ISO mounted in attempt 1, but no longer had it mounted (according to XOA), The other VM was one of the 2 VM's that failed in attempt 2. Again, there was no longer anything showing as mounted. Not sure why these 2 failed to Migrate back to Host1.

Since the Master Host was updated, I could no longer perform a Rolling Update. I migrated the 2 VM's (no changes to the guests - manual migrated completed normally), disabled HA on the Pool, and applied updates and then Rebooted Host. Host came back up normally and I was able to enable HA and move VM's to it.

So, my cluster is back to normal, but I wanted to put my experience out there in case it is useful. Working with various vendors over the years, I have found that I am VERY good at finding corner cases.

Overall, it seems like the Rolling Update functionality is a bit fragile, at least in my case. Maybe my ISO setup is unusual? It seems problematic that someone using Self-Service could leave a VM in a state that would cause headaches for Updates without the Updater detecting it and letting the XOA Admin know what the problem is. If I had hundreds of VM's created by multiple other people, it would have been hard to figure out what the issue was.

Let me know if I can provide any other useful info.

Thanks!

Greetings,

Wondering if anyone else has seen this. I am using up-to-date XOA on the latest channel. I recently enabled the Premium Trial and am testing the Premium features.

I was able to set up the auth-ldap plugin to talk to our AD servers and got groups importing and everything seems to be working normally. I then had a look at the Audit Log and found that successful logins via LDAP (AD) are being logged as "Sign in Failed". I tested and both good and bad logins show as failed in the Audit log. The local admin@admin.net user does not show failed on a good login.

Anyone else seeing this behavior?

I found this reference: https://github.com/vatesfr/xen-orchestra/issues/8351 that could be related I suppose. My users do have more than 6 group memberships, but auth is successful, just bad Audit info.

Update: I just tested with a user with exactly 6 groups and saw the same behavior.

Also, of note when a new user logs in, the Audit log is showing "Sign in Failed" with no user. The next time they login, it has the username along with "Sign in Failed". Not sure if the missing username on first login is expected.

Thanks!

kismetgerald-ngc created this issue in vatesfr/xen-orchestra

open LDAP/Active Directory Authentication Fails if User is Member of More than 6 Groups #8351

@olivierlambert ok, but it wouldn't have to. The guest tools always run the scripts (if they exist) when it sees a snap happening and then reports out the status the same way it says that the block commits are complete.

@olivierlambert So there is information coming from outside into the VM

Is there a particular reason not to implement freeze/thaw scripts in that case? The tools know there is a snap taking place and you said that you can write info from VM to outside, which would have to happen to tell the system that blocks have been committed and is ok to start. Seems like the communication is there, just need to implement the scripts.

Coming from VMware land, this is expected behavior of the guest tools.

I agree with OP, the webhooks looks janky, does not appear to be in the main docs, and the linked docs says it is unstable after 3 years.

@olivierlambert do the guest tools quiesce the filesystems before snapshotting?

@jr-m4 Seems useful to me for the tabs to be sticky. If you are flipping back and forth between sections to compare or work on something, having it always default to the first tab can be annoying.

@stormi The new installer boots fine on my systems. I was able to update my hosts from 8.2.1 to 8.3. Huzzah!

Thanks for all the hard work!

@stormi

Great! Thanks! I will test it out on my Dell R7525 hosts this afternoon.