XCP-ng 8.3 betas and RCs feedback 🚀

marvine

Is it known GPU passthrough dont work in 8.3 RC1 ?
i did the setup now through xen-orchestra and see it in windows but no matter what i do it keeps giving error code 43

Anonabhar

@marvine I dont know if that is true or not.. I am using 8.3 RC1 with GPU pass-through to NVidia Tesla cards with no problems (aside from the NVidia drivers being a pain in the backside to install under Linux).

Houbsi

@marvine said in XCP-ng 8.3 betas and RCs feedback :

giving error code 43

This error is a driver issue on Windows side.

It says that the card is "virtualised" Nvidia is very strong in blocking this, if it's not allowed.

If you google for it there should be plenty of workarounds.

marvine

@Houbsi yeah i did try it with the nvcleaninstall but gives me the same error and also tried the HV value to hide windows is virtualised.

Will try again to remove everything and start over

gskger

@marvine I am using two Nvidia P40 with passthrough to Debian VMs with XCP-ng 8.3 RC1. I had no issues with passthrough, installing and runing the P40. For Windows VMs, this older post might give some more information.

stormi

@CJ said in XCP-ng 8.3 betas and RCs feedback :

@stormi wait init shows exited with a success status. stunnel shows active and running.

I disabled the server and enabled it again and this time it connected without an error. However, it lists as unknown pool and doesn't show in any of the host/pool/vm pages.

Also, when I go on the console, it states that the host is already in maintenance mode. Selecting Enter/Exit Maint Mode results in the following.
(''NoneType' object has no attribute 'opaqueRef'')

Have you tried to reboot the server once again? If the issue persists, can you share /var/log/xensource.log somewhere (might contain sensitive information, so better share privately).

CJ

@stormi I have not rebooted the server at all. I told it to apply patches and then this all happened.

I didn't want to reboot it in case it was in the middle of something or if there were things you wanted me to check.

I'll try rebooting it and see what happens. Hopefully the other pools and nodes won't have this issue.

CJ

This will be fun. The console keeps losing connectivity with the VMs so I wasn't able to suspend them before rebooting the server.

Oh, that's not good. No change after rebooting. It's still borked. What's the best way to reach out to you, @stormi ?

stormi

@CJ You can send me a PM here.

CJ

@stormi Uh, how do I do that?

Also, I think the problem may be due to when I was attempting to set up a private network. I had deleted all of that but it seems to be stuck in a loop trying to find sdn-controller-ca.pem. Therefore the update never completes and it just tries again.

stormi

@CJ Then this would not be directly related to the update, but maybe just to the reboot that was performed by XOA after it?

stormi

Problem solved on chat. Our last update doesn't like it at all when a certificate was manually removed from the system without letting XAPI know.

So we had to:

revert the update and restart the toolstack - XAPI works again
touch /etc/stunnel/certs/sdn-controller-ca.pem to create back a dummy file for the missing cert, so that xe will accept to remove it from database (it fails if it can't find the file for which you're trying to remove the database entry )
xe pool-certificate-uninstall name=sdn-controller-ca.pem
update again
perform the update of the rest of the pool hosts

I added a comment in the issue related to the patches we included in this update to fix certificate fingerprints: https://github.com/xapi-project/xen-api/issues/5955

stormi created this issue in xapi-project/xen-api

closed fingerprint_sha256 and fingerprint_sha1 empty after upgrade for user certs in /etc/stunnel/certs/ #5955

BenjiReis

@brezlord So I managed to reproduce the issue: basically what's happening is lspci shows a shortened version of the PCI ID and the XAPI expects to parse a complete version of the ID so it fails while parsing. Removing manually the passthrough in the xen command line and re-adding it via XAPI should solve the issue.
Now that the API is available this shouldn't happen anymore as the only supported way of passing through a device is via XAPI.

Regards

brezlord

@BenjiReis Thanks for reproducing it. I suspected it was because of the manual pass-through.

stormi

We just published XCP-ng 8.3.0 Release Candidate 2. This should be the last one.

https://xcp-ng.org/blog/2024/09/17/xcp-ng-8-3-release-candidate-2/

I want to bring your attention to this:

I already installed XCP-ng 8.3 RC1 (or another pre-release). How do I upgrade to RC2?
You can upgrade as usual through Xen Orchestra or by using yum update. A reboot is required. However, we recommend upgrading via the installation ISO image before putting XCP-ng 8.3 into production. If you upgrade now for RC2, you won’t need to do it again for the final production release, and upgrading early helps us with testing.

CJ

@stormi For the last sentence, do you mean that if we use the ISO to upgrade to RC2 we won't need to use the ISO for final?

stormi

@CJ Yes

stormi

Reworded to:

You can upgrade as usual through Xen Orchestra or by using yum update. A reboot is required. However, we recommend upgrading via the installation ISO image before putting XCP-ng 8.3 into production. If you upgrade now using the RC2 installation image, you won’t need to upgrade again to the final production release (a simple update will then be enough). Upgrading early helps us with testing.

Does it seem clearer?

manilx

@stormi Upgraded my homelab pool (2 Protectlis VP6670) via ISO.
Master first and then 2nd host.

Only thing was that the master did not ask for network config and the 2nd host did ask for network configuration to use the repository BUT I did choose local repository...

After that all went fine.

What's the cli command to check the version?

olivierlambert

If yum update says no update or no updates visible in XO, you are good