Thank you guys! Problem temporarily fixed by Vates support,

@AtaxyaNetwork Hi yes, Sorry I'm not super experienced in this area at all.

I'm SSHd into the host and just ran dmesg -T in the root.

@AtaxyaNetwork What should we be looking for?

Seeing mostly messages about SMB i.e.

"No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount."

Hi,

I'll try and give as much detail as possible here but forgive me if I miss something.

We are experiencing host lockups or freezes when moving data around or doing backups of vms (XVA Exports). The host OS just freezes and becomes unresponsive resulting in a hard reset. Due to the nature of the crash/lockup we can't seem to find anything in crash or error logs but maybe we're looking in the wrong places.

We initially thought this could be a hardware issue so migrated vms from a problem host and ran a series of hardware tests including memory tests and data transfers over a period of a week. During our data transfer testing we noticed the host ram getting very low due to large amounts of cache/buffering from export to SMB mount with ram getting as low as 50mb free. We added some memory management parameter tweaks to start garbage collection earlier at 528mb rather than the default ~60mb. We added these tweaks as we had a theory that resource depletion on the hosts maybe causing issues when the amount free ram was getting too low and possibly causing a kernel panic/lockup.

We thought we were onto something but the lockups/freezes are still happening when performing XVA Exports (VM Backups). On reflection we've been experiencing these problems since we upgraded to 10gb NICs so were wondering if this could be the cause as the crashes tend to happen when data is being exported across the network to a backup location or another host. The NICs in use are Intel X540-T2 which were recommended in a previous forum post as good to use.

FYI our hosts are white box setups with consumer grade hardware other than the raid controllers and NICs. the hardware is as follows:

• Motherboard: MSI Z490A-PRO
• CPU: Intel I5-10500 3.1GHz (LGA1200)
• RAM: 128GB Kingston Fury Beast DDR4 3200 (CL16-20-20)
• Primary HDD: Western Digital Blue SN570 NVMe 250GB
• Raid: Dell PERC H710 PCIe
• Physical Disks for Raid, WD Gold 1TB
• PSU: Corsair RM750
• NIC: Intel X540-T2

Appreciate any guidance or help in diagnosing this issue.

Background: A scheduled backed that is not enabled is used as a place holder/template for remote triggering via XO API the actual VM to be backed up is set during the API call.

Issue: The VM shown in completed backups log in XO6 is the VM from the template and not the VM actually backed up. XO5 shows correctly, XO6 does not (unless I am missing something!)

Thank you guys! Problem temporarily fixed by Vates support,

@MathieuRA Hi I have a support tunnel open right now!

@olivierlambert Awesome, thanks for the update! I posted a ticket with support. Should I close it?

@Pilow I don't think we use port 80. I believe it redirects to https but we don't use a certificate and view the page non secure. It's only accessible on our internal LAN from specific IP addresses.

@Pilow

Nope, still same issue.

Hi, we've recently applied the latest updates and now under licensing we're being asked to register again. We are registered and on a monthly plan so all should be fine. Was all working prior to latest update to XOA 6.

Symptoms:
WebUI - Release channel has a spinner trying to show channels.
WebUI - Updater shows [object event]
WebUI - XOA -> License shows as not registered
Console - xoa-updater --register reports is already regsitered
Console - xoa check reports no issues found

Looks to me like the XOA5 webUI is out of sync with the underlying updater status as everything still seems to work.

Any ideas?