XCP-ng 8.3 updates announcements and testing
-
Yesterday, from memory: Up-to-date XO (CE) said there were Pool updates available, but the three individual XCP-ng hosts showed nothing available. I went to https://xcp-ng.org/blog/tag/security/ and did not see any new patches published for January, and I feared that the previous updates from October had somehow not been fully installed. I put hosts into Maintenance Mode and rebooted them, and patches were seemingly installed as part of the reboot. I don't recall if I rebooted (and therefore patched) the Master first or not as you are supposed to do. This was a bit unsettling.
As of this morning, Central Time US, for our three-node XS 8.4 Pool also managed by the same XO (CE), I see patches available in XO both at the Pool level and at the Host level as expected. (Yesterday, I did not see any patches reported by XO for our XS 8.4 Pool.)
-
@robertblissitt You can check
/var/log/yum.logon the XCP-ng hosts to see when the updates were actually applied, but there isn't anything in a standard installation of XO / XCP-ng that would trigger an "automated" update of missing patches. -
@Danp Thank you, and I could easily be misremembering how the patches got installed - I may have clicked a button (at the Host level?) to install them even though I could not see any to install. The other events I mention, however, I am more certain of.
-
applied latest patches to my two host pool without issue.
-
currently having heavy issues with a production cluster of 3 hosts
RPU launched, all VMs except one did evacuate the Master. we managed to shutdown this VM/restart it on another host
we had
Master patch & reboot proceeded
Then RPU tried to evacuate a slave host and all VM are now locked we can't shutdown/hard shutdown them,
we have a critical VM on this host that is still running, we tried to snapshot it in case of need of hard reboot of the host, but OPERATION NOT SUPPORTED DURING AN UPGRADE
we manually install patches on the host without reboot and then snapshot proceeded
I hope this VM is secured by this snapshot...ticket is open with pro support but quite stalled for now... no news since yesterday Ticket#7751752
-
That's a weird one
Ping @Team-Hypervisor-Kernel -
@olivierlambert shoutout to @danp that did a takeover of the incident ticket
he headed me the right way to resolution of the problem, my production pool is back up & running with its VMs.
there was indeed a diff between what was seen by "xl list"/"xenops-cli list" and what was seen by XOA in the web ui.
a couple "xl destroy pid" to destroy zombie VMs, and toolstack restarts later, all is now up.I don't know how the hell a simple RPU did get me in this situation though...
-
Oh wow. Indeed, that's strange. And big kudos to @danp then!!
-
@Pilow I've been wondering lately if I should do a Rolling Pool Reboot before any Rolling Pool Update. This might allow me to identify problems in advance and I would also be installing the patches on freshly-rebooted hosts.
-
@robertblissitt yup, afterward this seems to be a good best practice...
my hosts were up for 4 month, and because of DNS resolution problem had 77 patches to catch up (80 for one with advanced telemetry enabled)a rolling reboot would have probably put in front the initial migration/evacuation problem (and subsequent zombies VMs)
and no patches applied, and no pool in a semi upgraded state
note to my future self, try a rolling reboot first.
