Posts made by Forza

@Kajetan321 we use the digi anywhere USB 24 because we needed so many devices. But it works great. We also have a my-utn USB dongle server for year. Really good stuff both of them.

https://www.seh-technology.com/services/downloads/download-deviceserver/myutn-50.html

https://hub.digi.com/support/products/infrastructure-management/digi-anywhereusb-24-plus/

Thanks. Then, what about Linux guests? Most of mine seem to have this enabled, but not all. I do know that the Linux kernel supports Hyper-V extensions, so is it an advantage on Linux too?

Hi,

I just noticed a new toggle called "Viridian". What exactly does this do and what impact does it have if it is on or off?

https://github.com/vatesfr/xen-orchestra/issues/6572

There is a hotfix from Citrix that seems to indicate that viridian should be enabled for optimal performance. https://support.citrix.com/article/CTX258320/hotfix-xs80e003-for-citrix-hypervisor-80
I did check and it seems some vms have it enabled and others not.

RFWave created this issue in vatesfr/xen-orchestra

closed Add Toggle For Platform Viridian Status #6572

For now, a warning in XOA when changing the management IP would be nice. It could include an instruction on how to update the pool members after the IP of the master was changed.

Is it possible to use hostnames instead of IPs? It could make things easier?

@olivierlambert said in IP Address changed for a slave within a Pool, How do I reconfigure it?:

On a slave host, the database is in read only. If the slave lost the connection with the master, there's no way to make any change into the "local" slave XAPI database.

It makes sense. It would have been nice if pool members get the updated IP through XAPI before the actual change on the master happens.

@olivierlambert said in IP Address changed for a slave within a Pool, How do I reconfigure it?:

If you changed the master IP, the XAPI slave can't reach the master anymore, and so you can't make any modification via XAPI (since everything is going to the master, and then if needed to the slave).

On the slave, you might need to modify manually the master IP address in /etc/xensource/pool.conf. You should have:
slave:<OLD MASTER IP> and change it to slave:<NEW MASTER IP>

I had exactly this error an hour ago. I changed the management interface IP, but the member server could not re-establish contact. Looking in xensource logs I saw it was trying to connect using the old IP, but I thought this was stored in the xapi database and could not be updated...

@olivierlambert said in XCP-ng 8.3 public alpha :

It's an alpha not because it's unstable Just that we can make some updates before the official release. Happy to see it works well!

A thought. Is there a planned list of stuff that we can vote on to have on the next release?

@julien-f Would it help if I add the pool member to the "Servers" list as http:// ?

Thanks!

I tried the ESC option but could never get it to work. I thing the UEFI is set to 0s waiting time for boot options, which makes it tricky to time it.

Is it possible to change the default resolution in the VM templates for the UEFI resolution? It is possible to enter UEFI BIOS if you disable all boot devices, but it is a little cumbersome to adjust when creating new VMs.

Some more resources:

https://www.micron.com/about/blog/2020/february/numa-configuration-on-amd-rome-processors-and-nvme-performance-on-windows-servers

https://developer.amd.com/wp-content/resources/56827-1-0.pdf chapter 2.5 NUMA and CCX/CCD

@julien-f said in Backup jobs started to fail after last XOA update:

@Forza Yes, it's possible, simply prefix your host address by http:// in Settings/Servers.

If that does not work, open a support ticket and a tunnel and I'll investigate

This is why I was surprised. I have been using http:// for a long time now. But since I changed the "Unauthorized Certificates" it started to work again.

If you think it is important, I can open a tunnel for you to look?

@julien-f said in Backup jobs started to fail after last XOA update:

@Forza This is perfectly normal, XO is using HTTPS to connect to hosts by default for many years, and if you are not using an HTTPS certificate trusted by common authorities, you need to enable this setting.

I know https:// is default, but I remeber we could enable http:// to improve backup and migration performance. Is not possible any more?

@KPS I have no experience of a 2P system so far, so I cannot say : (

@KPS

I'd say that the EPYCs would be better than the Xeons no matter the NUMA per CCX setting. But, I would suggest looking at the EPYC genoa, which is 2-3x faster for the same cost as the previous EPYCs! Absolutely amazing performance and value.

https://www.phoronix.com/review/amd-epyc-9654-9554-benchmarks
https://www.phoronix.com/review/amd-epyc-9374f

Xen supports NUMA scheduling. The issue, I think, is whether the VM fits within a NUMA node or not, and if the application and/or guest VM understands NUMA in a guest environment. Only way to know is to properly benchmark the specific application with NUMA per CCX on or not and the number of cores you think the VM will need.

@olivierlambert said in Backup jobs started to fail after last XOA update:

Indeed, I use XOA with Enterprise license

Since the latest XOA update last week I am getting failed backup jobs. They look like this:

•	UUID: 5ee88933-d28a-f4ca-7dde-7490f3564398
•	Start time: Saturday, December 3rd 2022, 4:31:43 pm
•	End time: Sunday, December 4th 2022, 4:33:09 pm
•	Duration: a day
•	Error: self-signed certificate

It seems I had to enable "Unauthorized Certificates" in the servers settings to make backups work again. Is this a new setting or is this just a coincidence somehow?

Current version: 5.77.0 - XOA build: 20210102

- node: 18.12.1
- npm: 8.19.2
- xen-orchestra-upload-ova: 0.1.4
- xo-server: 5.107.1
- xo-server-auth-github-enterprise: 0.2.2
- xo-server-auth-google-enterprise: 0.2.2
- xo-server-auth-ldap-enterprise: 0.10.6
- xo-server-auth-saml-enterprise: 0.10.1
- xo-server-backup-reports-enterprise: 0.17.2
- xo-server-netbox-enterprise: 0.3.5
- xo-server-telemetry: 0.5.0
- xo-server-transport-email-enterprise: 0.6.0
- xo-server-transport-icinga2-enterprise: 0.1.1
- xo-server-transport-nagios-enterprise: 1.0.0
- xo-server-transport-slack-enterprise: 0.0.0
- xo-server-transport-xmpp-enterprise: 0.1.1
- xo-server-usage-report-enterprise: 0.10.2
- xo-server-xoa: 0.17.0
- xo-web-enterprise: 5.108.0
- xoa-cli: 0.33.0
- xoa-updater: 0.45.0

Looking at the error log I see that XOA is trying HTTPS instead of HTTP when communicating with the XCP-ng host:

"result": {
        "code": "DEPTH_ZERO_SELF_SIGNED_CERT",
        "url": "https://10.254.9.2/export/?ref=OpaqueRef:3377f666-5fdc-41e5-aebf-39c7ffa5ad3f&use_compression=zstd&session_id=OpaqueRef:dd989ec7-60ac-45af-8fcd-faf542f8e62a&task_id=OpaqueRef:5617043e-af92-4023-9482-043094180083",
...
        "VM": "OpaqueRef:3377f666-5fdc-41e5-aebf-39c7ffa5ad3f",
        "message": "self-signed certificate",
        "name": "Error",
        "stack": "Error: self-signed certificate\n    at TLSSocket.onConnectSecure (node:_tls_wrap:1538:34)\n    at TLSSocket.emit (node:events:513:28)\n    at TLSSocket.patchedEmit [as emit] (/usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/log/configure.js:135:17)\n    at TLSSocket._finishInit (node:_tls_wrap:952:8)\n    at ssl.onhandshakedone (node:_tls_wrap:733:12)\n    at TLSWrap.callbackTrampoline (node:internal/async_hooks:130:17)"
      }

@olivierlambert OK thanks for the info. What is the plan for leaving the old CentOS 7?

Great to see the next iteration of XCP-ng

What is the status on the base OS choice for XCP-ng instead of CentOS?

@julien-f The problem was on TrueNAS side. Apparently the way it handled permissions for NFS shares changed when upgrading from TrueNAS 12 to 13....