I installed all these updates for 8.0 and rebooted the host.

The reboot was extraordinary long. The time from shutting ssh session to getting ping packets back again was about 8 minutes. I don't know what it was doing during all this time as I rebooted remotely.

So I rebooted once more to see whether the boot time would be so long again.
This time it was only 1 minutes 46 seconds.

The VMs seem to run OK so far, but it's just a test host with two VMs doing almost nothing, so I don't know for sure :-).

@jcpt928 said in XCP-ng and NVIDIA GPUs:

I have taken the approach of ensuring my VMs, my network, and my edge is secure - if someone can't get into something and run something that takes advantage of the bug in the first place, that's all that really matters.

I seem to remember this question asked at this forum, but can't find it...

Do you use browsers?

@woopla I'm not sure if this will work in your setup, but I've thought I'll share the solution which worked for me as I tried hard to get rid of bloody framebuffer (which was making the console in XCP-ng Center and in XOA almost unreadable due to tiny or blurred font).

After many hours of googling and trying various settings in /etc/default/grub (which theoretically should work, but didn't) I found unix.stackexchange.com/questions/346090/disable-framebuffer-in-qemu-guests.

It advised:

" disable the framebuffer via a bochs_drm module parameter - i.e. via setting it on the guest kernel command line: bochs_drm.fbdev=off "

Precisely, I put into /etc/default/grub the following line:

GRUB_CMDLINE_LINUX_DEFAULT="systemd.show_status=1 bochs_drm.fbdev=off"

edit: I forgot to mention: the above line is for a VM system, not for XCP-ng host.

(The systemd entry is unrelated to fb issue, but I'm quoting it here as a additional tip - I need it to at least partially work around systemd fascist plague).

I wonder: will this bochs tip help you?

You're welcome!
I'm happy I could help a little. I'm grateful for XCP-ng!

Congratulations!

@borzel, many many thanks for work on XCP-ng Center!
Without XCP-ng Center, administering XCP-ng would be much more difficult and risky (error-prone) for me.

Guys, you really deserve it!
Congratulations!!

@woopla I'm not sure if this will work in your setup, but I've thought I'll share the solution which worked for me as I tried hard to get rid of bloody framebuffer (which was making the console in XCP-ng Center and in XOA almost unreadable due to tiny or blurred font).

After many hours of googling and trying various settings in /etc/default/grub (which theoretically should work, but didn't) I found unix.stackexchange.com/questions/346090/disable-framebuffer-in-qemu-guests.

It advised:

" disable the framebuffer via a bochs_drm module parameter - i.e. via setting it on the guest kernel command line: bochs_drm.fbdev=off "

Precisely, I put into /etc/default/grub the following line:

GRUB_CMDLINE_LINUX_DEFAULT="systemd.show_status=1 bochs_drm.fbdev=off"

edit: I forgot to mention: the above line is for a VM system, not for XCP-ng host.

(The systemd entry is unrelated to fb issue, but I'm quoting it here as a additional tip - I need it to at least partially work around systemd fascist plague).

I wonder: will this bochs tip help you?

@stormi said in Updates announcements and testing:

I'll need at least one tester for the latest update candidates on XCP-ng 7.6, and one for 8.0.

At 8.0:
I did yum update, but there are only new versions of guest-templates-json*, so can't quite see anything to check.

Just in case I rebooted the host. The reboot took about 1 minute 40 seconds which i s OK for this host.

The test VMs started OK as well.

I installed all these updates for 8.0 and rebooted the host.

The reboot was extraordinary long. The time from shutting ssh session to getting ping packets back again was about 8 minutes. I don't know what it was doing during all this time as I rebooted remotely.

So I rebooted once more to see whether the boot time would be so long again.
This time it was only 1 minutes 46 seconds.

The VMs seem to run OK so far, but it's just a test host with two VMs doing almost nothing, so I don't know for sure :-).

@stormi said in Updates announcements and testing:

XCP-ng 7.6

[...]

microcode_ctl

yum update microcode_ctl --enablerepo=xcp-ng-updates_testing

Microcode update for the SandyBridge family of CPUs regarding the MDS attacks.

Post-install: reboot if you want it to be taken into account.

xcp-ng-pv-tools

yum update microcode_ctl --enablerepo=xcp-ng-updates_testing

I guess that above command for xcp-ng-pv-tools should not be the same as the one for microcode_ctl

XCP-ng 8.0

[...]

microcode_ctl

yum update microcode_ctl --enablerepo=xcp-ng-updates_testing

This command returns error:

# yum update microcode_ctl --enablerepo=xcp-ng-updates_testing
Loaded plugins: fastestmirror


Error getting repository data for xcp-ng-updates_testing, repository not found

I guess it meant to be:

# yum update microcode_ctl --enablerepo=xcp-ng-testing

as this worked for me.

HTH

@stormi said in XCP-ng 8.0.0 xsconsole doesn't show Host Performance Information nor VM's CPU and Memory Usage:

I wanted to have a look at the commit history for xsconsole but the github repository at https://github.com/xenserver/xsconsole

Thank you, @stormi

I've opened a bug report at bugs.xenserver.org about it

Specifically: https://bugs.xenserver.org/browse/XSO-961

. Now you may want to open a bug report there about the missing information in the console. This could allow to know if it's a bug or a "feature".

Good idea. My bug report:
https://bugs.xenserver.org/browse/XSO-962

@olivierlambert I installed Citrix Hypervisor 8.0.0 as a VM.
In the Host Performance Information:
"CPU Usage" and "Memory Usage" are Unavailable like in XCP-ng 8.0.0

Pity!

I couldn't check this information in VM submenu, because XOA installation failed (no hardware virtualization support (or similar wording) in the nested hypervisor).

@olivierlambert said in XCP-ng 8.0.0 xsconsole doesn't show Host Performance Information nor VM's CPU and Memory Usage:

This was probably removed in upstream, we didn't touch anything like that.

I remember (and can see) you've modified xsconsole recently (at least colours), so I thought that something could change by accident as well.

So the question is why Citix removed it? I suppose there's reasons for that.

Maybe for a reason, maybe not. Bugs happen.

Would you (XCP-ng developers) mind checking it in Citrix Xenserver? You probably have it installed and checking whether this issue is present there as well won't take much time, please?