Then reboot in the next maintenance window

You should really start by getting all your hosts up to date first, reboot after updates and see if it happens again, while trying to fix your connectivity problem to your network shares.

@Andrew7 this mindset won't be really constructive if you want some free assistance on a free product.

@dinhngtu might help if he's around.

Double check your hosts are fully up to date (which version? you haven't provided many useful information on your environment in your first post )

Hi,

If you use a remote storage for VM disks or ISO, you must be sure the connection is stable. Otherwise, having issues is rather normal. It's like physically cut a SATA cable to your DVD/CD drive. You need to understand why you lost the connection to your SMB/CIFS share in the first place.

Hi,

That's 2 very different things. Ping @julien-f for audit logs (or @Bastien-Nollet if he's around). For XO logs, same people to ping. For XCP-ng log rotation, it's another completely different story. Have you took a look at https://docs.xcp-ng.org/guides/logs/#logrotate?

What if you disable the "VGA" in the XO UI, is it better?

How are you doing remote desktop? (ie via which mechanism).

I need to check internally what's the highest resolution possible for a VM, I don't have this data.

Because you have graphic performance issues in the first place? Can you be more specific?

The plugin was initially created to check RAID created during install, not custom RAIDs created manually. But that could be an improvement to the plugin @stormi I leave you the honor to add this somewhere

How did you create your RAID in the first place?

Question for @dinhngtu

Before answering your question, that would be good to get already something to compare. Can you try with XO and see if it's similar? It's important to understand, if the problem is related to XCP-ng or your backup solution. Also, why not asking CommVault directly too?

Keep us posted if you are stuck again, let us know

Your doc is probably better than what you can find in 90% of the companies we worked with, including ourselves

In theory, if the raid was created using the installer (so during installation), you should have /dev/md127. That's what the plugin checks:
https://github.com/xcp-ng/xcp-ng-xapi-plugins/blob/master/SOURCES/etc/xapi.d/plugins/raid.py#L18

Hmm that would be interesting to check manually the plugin report:

xe host-call-plugin host-uuid=<uuid> plugin=raid.py fn=check_raid_pool

I strongly suggest that you use your good relationship with them to push the topic. More people are coming to them to ask for support of XCP-ng, great the chances to be sold as a product

That's probably the issue (MTU mismatch). It's very likely "MTU 9000 everywhere" isn't true and that's causing the problem. Please review first that MTU is correctly set to the same value everywhere.

@Virtual said in Cannot get to XO Lite portal:

@olivierlambert So my host IP is 192.168.1.40 and the Xen orchestra IP is 192.168.1.45

To clarify, I was referring to XO 6 Lite. Going to https://192.168.1.40 brings up the page with XoA quick deploy, cli documentation, etc. It doesn’t navigate to XO 6 lite

Going to https://192.168.1.45/v6 still gives me the error mentioned in the original post

Indeed, as said, there's no such thing as "XO Lite 6". XO Lite is simply "XO Lite" (we'll have a v1 at some point, v6 is like far far in the future )

So yes, https://192.168.1.40 should display XO Lite if you use XCP-ng 8.3 (you can install it manually for 8.2 but it's not bundled by default)

And https://192.168.1.45/v6 should display XO 6, only if you built it correctly to get XO 6 components built.