Rolling Pool Update succeeded on the master but then failed on the first slave, due to yum caching errors. This resulted in a finished failed task of RPU. I've corrected the yum issue and manually updated and rebooted this slave.

Now, when I go to Pools > Patches, it shows there are no missing patches, so the RPU button is disabled. This is true for the master and one slave but the remaining slaves are still missing their patches. It seems XO is just checking the pool missing patches on the master, ignoring the other slaves.

I guess I have two options:

• wait for the release of a new XCP-ng patch, so that the RPU is enabled once again
• manually update each host

Shouldn't XO check for Pool missing patches on all hosts, and allow a RPU to be performed if there is any host with missing patches?

Orchestra, commit 6ecab
Master, commit 6ecab

@kagbasi-ngc You can go to Settings > Logs to display the details of that resources error message. It should say something such as this:

vm.snapshot
{
  "id": "7f3d5995-3ab8-bfd5-ec72-c36e98d8cc70"
}
{
  "code": 24,
  "data": [
    {
      "resourceSet": "UXh2bwwr9Lo",
      "resourceType": "cpus",
      "available": 0,
      "requested": 4
    }
  ],
  "message": "not enough resources in resource set",

From my tests, you need to have free cpu, ram and storage of the same amount of the VM. So, to be able to snapshot that VM you would need 2 cpus and 16 GiB of ram in the resource.

@stormi OK, thanks, I'll finish upgrading the other hosts.

@stormi Thanks for your suggestions. I've tried to enable it on the pool:

# xe pool-enable-tls-verification
This operation is not supported during an upgrade.

I have to finish the upgrade of the other hosts before enabling it on the pool.

As for disabling it on the new host, I didn't find any way to do it permanently. I just found the host-emergency-disable-tls-verification option, which does not disable it completely, and doesn't allow to add it to a pool without TLS verification. Would you clarify how to disable it on the new host?

I will enable it on the pool when the upgrade is finished.

@stormi I've upgraded the master in BIOS mode, and proceeded to reinstall one of the other hosts in UEFI mode, after having removed it from the pool. It went fine, until I tried to add the host back into the pool. This was not possible because the reinstalled host has Certificate Verification enabled, while the pool doesn't. Even if I host-emergency-disable-tls-verification, it's not possible to add the server back into the pool.

It seems I'll have to upgrade the other hosts in BIOS mode, enable certificate verification on the pool and then add this host. I guess I'll reinstall the other hosts in UEFI mode on a future upgrade.

While installing 8.3 RC1 it says BIOS boot mode is deprecated and I should use UEFI. But if I boot in UEFI, when I choose to upgrade the existing installation, an error occurs: "Installer mode (UEFI) is mismatched with target host mode (legacy)".

To be clear, it is not possible to migrate from BIOS mode to UEFI during an upgrade?

In that case, the only option would be to remove the host from the pool, install XCP-ng (not upgrade) and then add it to the pool. Am I correct? Thanks.

Congrats on this release! I've done a 'yum update' on a XS 7.5 on a host with a Qlogic fibre channel HBA. It updated to 7.6 and the HBA works as expected. Qlogic management tools are useful if one wants to tweak HBA parameters or update its firmware. They are not needed for everyday usage.

On a test machine, I've upgraded from Xenserver 7.2 directly to this version and it worked fine. I've used PXE network installation to upgrade.
Congrats on this release!