After NUT's grand reconfiguration there are a few things that you need to be aware of:

In order to run NUT as a monitor to shut down your XCP-ng hypervisors it is no longer sufficient to just install nut-client and enable nut-monitor.

You also need to install nut and enable nut.target or nut-monitor won't autostart. There won't be anything in journalctl either, since it isn't even trying to start - the thing that tells it to do so is the nut.target and if that's missing nothing will ever trigger.

yum install nut nut-client --enablerepo=epel

make your edits in nut.conf and upsmon.conf then

systemctl enable nut.target 
systemctl enable nut-monitor 
systemctl start nut-monitor

@Greg_E I forgot to mention a potentially important step just before the reimage from BIOS -> UEFI.

After you've drained the host disconnect it from the pool.

so:
reimage all hosts in whatever mode they're in
migrate all VMs from the target to be changed to UEFI
disconnect said target from the pool
reimage target with UEFI boot
reconnect target to the pool

nomad

@Greg_E I saw a similar thing and dealt with it thusly:

Upgrade the master in BIOS to preserve the configuration
Upgrade second (only other, in this case) host in the pool using UEFI boot
Migrate 'master' status to the second host
re-install the first host with UEFI, re-join it to the pool.

Before doing this take careful note of the xe pool-enable-tls-verification mentioned in the release notes. You won't be able to join the cleanly reinstalled host without it.

Typing 'master' so many times has me wishing we had a better word for the pool coordinator.

When upgrading an 8.2.1 pool is it safe to issue the commands

secureboot-certs install
xe pool-enable-tls-verification

as soon as the master is upgrade (all other hosts hosts still running 8.2.1) or does that need to wait until all hosts are updated?

@stormi I see plug-late-sr is available now. Just finished testing it. Looks like it works just fine.

thanks

@stormi I'm glad to know I was slightly right about some of the way it works anyway.

@stormi If it's the exact same thing just with a different version number I can wait for a future update. I already have the -12 RPM in my yum repo for automatic install on all VMs.

I was looking to see if there was any notable changes from what we already had as well to see if an icon for AlmaLinux would show up in the home -> VMs list (everything else has an icon showing the OS running on the VM, just poor Alma is left all alone at the display ball.)

Ok, I'm feeling dumb. I just mounted the guest tools ISO (hosts -> hostname -> console -> "select disk(s)" pulldown, select "guest-tools.iso") and I'm seeing kinda old versions of xe-guest-utilities (-2 instead of -12).

: || lvd@vm42 ~ [1023] ; ls -l /media/Linux/xe-guest-utilities*rpm
-r--r--r--. 1 root root 985556 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.i386.rpm
-r--r--r--. 1 root root 985384 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.legacy.i386.rpm
-r--r--r--. 1 root root 1246820 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.legacy.x86_64.rpm
-r--r--r--. 1 root root 1247000 Dec 11 2023 /media/Linux/xe-guest-utilities-7.30.0-2.x86_64.rpm

When I do the same on my production 8.2.1 pool I see

: || lvd@chipmunkdev ~ [1000] ; ls -l /media/Linux/xe-guest-utilities*rpm
-r--r--r--. 1 root root 985488 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.i386.rpm
-r--r--r--. 1 root root 985308 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.legacy.i386.rpm
-r--r--r--. 1 root root 1246760 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.legacy.x86_64.rpm
-r--r--r--. 1 root root 1246948 Feb 7 2024 /media/Linux/xe-guest-utilities-7.30.0-12.x86_64.rpm

Should I be looking somewhere else for the most recent xe-guest-utilities?

@nomad said in XCP-ng 8.3 betas and RCs feedback :

plug-late-sr

Looks like this RPM isn't available in 8.3 yet. Please remember to make it available as we need it.

It was created for Ticket#7714169

thanks!

@stormi It was user error.

/etc/hosts wasn't preserved and the storage NAS isn't in DNS.

I decided to try upgrading my master to 8.3 in BIOS mode (see yesterday's post about UEFI failure). The upgrade seems to have gone well overall but when I try to access my NFS-mounted SRs I get

"SR_BACKEND_FAILURE_140(, Incorrect DNS name, unable to resolve., "

Evidently not everything was preserved in the upgrade.

I tried to upgrade my test cluster from 8.2.1 but encountered a few problems. I was basically trying to follow the instructions at https://docs.xcp-ng.org/installation/upgrade/ by doing a install from media (USB Key).

1. screen resolution. Perhaps an option for a lower resolution console would be reasonable?

(I tried linking a screenshot but the forum software objected. It can be found at https://photos.app.goo.gl/Zkby9aHUEBYUzkfe8 )

My KVM display was upset by the resolution selected and put a splash screen in the middle of the display saying "Input sync out of range. Please select 1024x768 60Hz for best performance."

note: this only happens with a UEFI boot. It does not appear with a BIOS boot.

2. lack of information about what non-standard things are in the way so they can be found and removed.

Another photo: https://photos.app.goo.gl/ZuTNKiXctUCBkSmf7

"Only product installations that cannot be upgraded have been detected. Continuing will result in a clean installation, all existing configuration will be lost. ..."

This box started as a default 8.2 host and was upgraded to 8.2.1 via yum. The only truly non-default thing is the package that enables waiting for NFS RSs to become available before starting any dependent VMs (plug-late-sr-1.1-1.xcpng8.2.noarch).

I removed that one RPM but still had the same error.

Hmm. I just remembered the first time I tried this I did get a warning about changing from BIOS to IPMI so I went in and changed boot mode. I guess I should go try booting from BIOS and see if that changes/removes the error....

Yep, sure does. No error at all when booting in BIOS mode. So, the message about installing with UEFI instead of BIOS might want to be re-worded to make it clear this is not an upgrade option. (and to perhaps suggest the best method for making said change?)

I've held off on applying the upgrade incase you wanted me to test something.

I'm migrating from VMware 7 to the most recent XCP-ng. I've just started using XCP-ng after years with VMware.

Today I noticed that hosts I image on XCP-ng don't change grub2 to use the most recent kernel even though it's installed during a dnf update. I do not have this problem with bare-iron or VMware-hosted hosts. Even hosts that I start on VMware then move to XCP-ng via VMDK -> OVA -> VDI update correctly. It's just hosts imaged on XCP-ng that have a problem.

The hosts are all using UEFI. The OS being installed is CentOS Stream 8. I'm creating the VM in XOA, selecting the "CentOS 8" template then changing the boot from BIOS to UEFI.

I'm imaging hosts on VMware and XCP-ng using the exact same ks.cfg file except "--drives=sda" Vs "--drives=xvda".

On investigation I see a missing line in /etc/default/grub on the hosts that aren't updating properly:

  GRUB_ENABLE_BLSCFG=true

I can get things working with:

sudo dnf reinstall -y grub2-tools-2.02-129.el8.x86_64
sudo dnf reinstall kernel-core-4.18.0-448.el8.x86_64 kernel-4.18.0-448.el8.x86_64

The first rebuilds /etc/default/grub, inserting missing ENABLE line and the second properly updates grub2.

Of course, I'd really prefer to have hosts properly configured on install so I don't have to play games with puppet or other management tools to make sure this line is present.

Is there a XCP-ng setting I'm missing? Anything else I'm obviously overlooking?

thanks,
nomad