XCP-ng 8.3 updates announcements and testing

rzr

@JeffBerntsen said:

@rzr

I'm seeing 30 updates as well but they're installed and seem to be working fine on my test systems.

I think I only listed sources packages (which contains several binaries sub-packages having the same versions), so that's expected

BTW thank you for reactivity on testing

stormi

Indeed we only list source packages. xapi's source RPM alone creates a lot of RPMs each time, for example. In this case, all those with version 26.1.4-3.1.xcpng8.3.

ph7

@rzr
Seems to be OK
ran a few backups and installed a new VM
XO-lite was already on 0.21.0 (13f98) after the update 2 weeks ago.. Don't know if it's the same.

flakpyro

Installed on my usual batch of test hosts, so far so good.

rzr

@ph7 said:

@rzr

XO-lite was already on 0.21.0 (13f98) after the update 2 weeks ago.. Don't know if it's the same.

yes it's same landed in testing before and not yet moved to updates, btw this version does not bring much change as it's a rebuild with dep update, see there is no full changelog :

https://github.com/vatesfr/xen-orchestra/releases/tag/xo-lite-v0.21.0

Andrew

@rzr Updated and running on most systems now. Rolling pool reboot worked correctly (need to disable backups first). VMs and CR running normally.

After a large S3 backup session (that succeeded), GC on the master got stuck in a loop and failed (lock issue). A reboot of the pool master was required to resolve the problem then GC coalesced the VHDs without additional action. Other pools did not have the same problem. I have not seen that issue before, but everything seems fine now so I can't blame the update.

Greg_E

@Andrew

Why did you need to disable backups before applying this?

Andrew

@Greg_E It's not a patch/update issue, it's the rolling pool reboot. If a VM is being backed up and XO wants to migrate the VM and can't, then the host evacuate stops and the reboot does not happen.

dthenot

@Andrew Hello,

I'm also getting error on some VMs while trying to export a disk and also trying to even start some VMs from NFS (that were fine before).

Is it still a problem? It might have multiple causes. If it's still an issue, could you share the logs: /var/log/{SMlog,xensource.log,daemon.log}. It contains information that could help us investigate.

The VDI not detached cleanly means that the VDI still has a reference to the host it was running on before.
It's might be caused by the xenopsd error earlier or maybe it's the cause.

If you are sure no tapdisk are using the VDI, you can look at tap-ctl list output on each host.
You can clean this reference with the script in /opt/xensource/sm/resetvdis.py single <VDI UUID>.

Greg_E

@Andrew

Thanks, my updates and my RPU are normally at different times. I also don't backup multiple times per day like I probably should.