XCP-ng 8.2 updates announcements and testing

stormi

@codedmind when it got to the point that you ran out of inodes in /var/log, you need to remove some files before you can update. find /var/log -name ovsdb-server.log.*.gz -delete should work (untested, try without -delete first). Else look at the other threads that covered the subject.

codedmind

Ok thanks!

rechotech

Does the openvswitch bug cause the local storage to fill up, or just the log file?
Would this openvwswitch potential lead our XCP server to crash?

stormi

Local storage is not touched. Only the /var/log partition, or the / partition if you have no /var/log partition. In the latter case, I suppose this could hang or crash the server. In the former case, it prevents some new tasks to be performed, but we haven't had reports of crashing servers at this stage.

rechotech

since this is unlikely the cause of our crash, where would you suggest we look to determine why our xcp servers crashed a few days ago?

stormi

I suggest opening a dedicated thread with as much information as possible.

stormi

As a starting point, see https://github.com/xcp-ng/xcp/wiki/Logfiles and look for whatever happened by the time of the crashes, if logging was still operational at that moment.

stormi

For XCP-ng 7.6 only

New security update for the latest Intel CPU vulnerabilities:

http://xenbits.xen.org/xsa/advisory-297.html

Install it with:

yum update --enablerepo='xcp-ng-updates_testing' microcode_ctl-2.1-26.xs5.x86_64 xen-dom0-libs-4.7.6-6.5.1.xcpng.x86_64 xen-dom0-tools-4.7.6-6.5.1.xcpng.x86_64 xen-hypervisor-4.7.6-6.5.1.xcpng.x86_64 xen-libs-4.7.6-6.5.1.xcpng.x86_64 xen-tools-4.7.6-6.5.1.xcpng.x86_64

There's nothing fancy in the way the updates were built so no breakage is expected, but we still need feedback from early-adopters before we push them to everyone.

Reboot required.

Downgrade if needed with:

yum downgrade microcode_ctl xen-dom0-libs xen-dom0-tools xen-hypervisor xen-libs xen-tools

What to test:

basic functions of the hypervisor, VMs...

Read the advisory carefully: installing the updates is not enough. There are other steps to be taken for complete protection.

Citrix announcement: https://support.citrix.com/article/CTX251995

Ultra2D

@stormi said in Updates announcements and testing:

yum update --enablerepo='xcp-ng-updates_testing' microcode_ctl-2.1-26.xs5.x86_64 xen-dom0-libs-4.7.6-6.5.1.xcpng.x86_64 xen-dom0-tools-4.7.6-6.5.1.xcpng.x86_64 xen-hypervisor-4.7.6-6.5.1.xcpng.x86_64 xen-libs-4.7.6-6.5.1.xcpng.x86_64 xen-tools-4.7.6-6.5.1.xcpng.x86_64

Should the pool master be updated first? Or it doesn't matter for there updates?

stormi

@Ultra2D Yes, always the pool master first.

stormi

@Ultra2D Technically, some updates could be installed in any order, but it's safer and simpler to consider that master is always updated first.

Ultra2D

@stormi Sure, but I'd rather test on a pool member first if trying as an early adopter .

stormi

@Ultra2D For this update, I think you could try with a slave first, since it's only an update of xen (and microcode_ctl), so I don't expect incompatibilities in pool management. But I wouldn't guarantee that cross-host operations such as migrations would work fine.

Ultra2D

@stormi I'll try it on a master, no worries. But not on a Friday.

borzel

@stormi installed just now all latest patches from updates testing via yum on my testbox at work
--> server bootet fine
--> VMs bootet (Debian 9, Ubuntu 18.04, all PVHVM)

stormi

Upping this thread in the hope for more test results.

rizaemet 0

@stormi installed on our pool hosts. Hosts boot normal. No vm boot issue Linux and Windows.

stormi

I have pushed the update to the updates repo. Security bulletin should follow shortly on the blog.

Ultra2D

Installing now, seems to run fine.

stormi

Announcement live: https://xcp-ng.org/blog/2019/05/21/xcp-ng-security-bulletin-mds-hardware-vulnerabilities-in-intel-cpus/

Was a long write but should be a short read