@Dataslak I have tried the "Enable"-button too, yielding same result.

@rmarion If you are seeing this on a an XOA, open a support ticket and a support tunnela and we'll investigate directly 🙂

@mr_zz welcome to the forum 🙂

Right, so yeah I did just that - disabled HA and have been keeping an eye on the logs as well as general performance in the env. Glad to know my actions align with your recommendations at least 😆

There are a couple of hosts that get a lot of these sorts of messages in the kern.log:

Am I wrong to attribute this to issues within specific VMs (i.e. not a hv performance issue)?

I know one of the VMs that causes these is a very old centos 5 testing VM one of my devs use and the messages stop when it's powered down.

Is there any way to easily associate those vifs with the actual VMs they are attached to? My google-foo failed me for that.

Other than that, I noticed my nic firmware is a bit old on the X710-da2's I use so I'm going through and upgrading those with no noticeable changes. I'm fairly hesitant to re-enable HA without tracking down the root cause.

Thanks everyone here for the feedback!

@DwightHat said in Stuck in maintenance mode after joining pool.:

When I try to look at the host in Xen Orchestra it just says "An error has occurred".

Check to browser's Dev Tools console when this happens. It will likely contain some additional details.

You likely need to check the logs to find out why you are encountering this issue. Many times the "stuck in maintenance mode" issue is related to an unmountable storage repository.

https://docs.xcp-ng.org/troubleshooting/log-files/

@manilx I agree about snapshots. I don't know how we can checkpoint a VM without suspending it (I think it shortly suspends it and them resumes it), so I have trouble understanding XenServer's statement.

@gskger Yes, all my VM's have guest tools installed, Windows/Linux. It's quite the "requirement".

This post specifically: https://xcp-ng.org/forum/post/57441

The person had issues to speak in English but wanted to tell this configuration worked.

You can use the xen_wdt backend to rely on a Xen operation to force restart the VM. I have no idea how it works on Windows.

@lawrencesystems I think this is quite common when you need to test certain scenarios with multiple hypervisors (backup, migrations, etc.). You only need a couple of HVs with a few tiny running VMs. We have done this setup with nested esxi many times for testing purposes. And since e.g. Ubuntu and Windows work this way, the problem is probably specific to Debian (and maybe others?).

Question for @gduperrey or @stormi

@infodavid Finally, I follow an existing topic and configure nut-server on the hypervisor to access the ups via usb.
I know that Olivier is not fully aligned with the fact that the host is modified but IMO it is an acceptable change on my XCP-NG host.

@jasonnix XOA does the primary things Veeam does. Backups, backup copies, full/incremental replication, and file level restores. The only thing I've ran into that XOA can't do is something like restoring active directory objects directly to a domain controller, or native SQL Server level restores without having to restore the whole VM. Those are the only instances where I'd consider running the Veeam agent directly. XOA works perfectly otherwise.

@lritinfra Something to consider also the HPE Intelligent Provisioning is the main way, outside of HPE iLO, HPE SUM or HPE SPP to update the server's hardware firmware. If you aren't using individual RPMs or SCEXE files for the task. With HPE Intelligent Provisioning and HPE SPP being able to update, both firmware and BIOS.

As not all of the updates for firmware will be in a compatible format, for use with HPE iLO. I'm not sure if it has changed but an Administrator Password set on the BIOS (at minimum), also locks out (disables) access to the Erase option on the HPE Intelligent Provisioning. At least it does on my only HPE Server running an up to date BIOS, HPE iLO and HPE Intelligent Provisioning.

Thus disabled HPE Intelligent Provisioning doesn't help with being up to date enough to fix vulnerabilities and bugs at hardware or firmware level.

@rjt Note to self about creating and managing appliances at xe cli.
xe help --all | egrep -i '(appliance)' # find xe appliance related commands.

@abudef
I ran into the same thing on a dell latitude 5411, but I eventually found a workaround. In the BIOS under System Configuration there was an option called Unobtrusive Mode, and when enabled, a specific key combination will turn off the display and speakers, independent of the OS. The same key combination will then turn them back on when needed.

While an automatic feature would be preferable, the manual option meets my needs since it would be rare to need to use the laptop screen. The one downside for me is that if power is lost long enough that the battery drains, the screen will need manual intervention after power is restored - the BIOS will turn the machine back on when it receives power, but won't put the screen back in its previous state.

I put a sticker on the laptop with the key combination so I will remember it when needed.

@sushant-diwakar I think you misunderstood @olivierlambert as he was referring to the support ticket that you opened with Vates, which is still open and awaiting a response from you.

I restored the forum thread that you deleted because it contains information that is pertinent to this discussion. I'm leaving this topic separate for now, but IMO there really was no valid reason to start this new thread instead of continuing the prior one.

@sushant-diwakar

@ImThatFluffy said in Issues with PCIE Passthrough:

@john-c

Yea im not sure, it was either an issue with the way I had Debian setup or compatibility things booted up Ubuntu 22.04LTS with the HWE kernel and it worked perfectly.

Well if you are using Ubuntu Linux 22.04.1 LTS or one of the later point releases then it would be using a Linux Kernel version 6.1 or later, when its a HWE kernel. So any bugs from earlier versions of the kernel would have been fixed, also the Intel ARC graphics hardware would have been released during one of the point releases. On the Debian Linux front a distribution version earlier than version 12.0 would have been unlikely to have complete properly functioning support, due to that release being the first one with the Linux kernel version of 6.1 or later.