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?

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

FWIW, I'm seeing the same thing. Have you tried this in Xenserver 8.0? That would help determine where the change in behavior occurred.

No, because currently we don't use Citrix Xenserver.

P.S. I imagine most people get this information from either XO or XCP-ng Center.

Sure, I use XCP-ng Center as well.
But xsconsole is very important for us for remote ssh access and for direct console access in the server room, especially during maintenance tasks, updating, rebooting etc., when xsconsole enables us to shutdown, start and verify that particular VMs in fact started and are running etc.

Hello.

After upgrading a host from XCP-ng 7.6.0 to 8.0.0 I noticed that xsconsole's functionality decreased.

In Virtual Machines
--> VMs Running On This Host
and
--> Host Performance Information
and
--> All VMs

no longer are displayed "CPU Usage" and "Memory Usage".

Here you are examples:

1. In 7.6.0:

│ VMs Running On This Host               XOA                                   │
│                                                                              │
│ VM1                                    Power State      Running              │
│ VM222                                  Memory           2.0GB                │
│ VM333333                               CPU Usage        0% of 2 CPUs         │
│ VM4                                    Memory Usage     61% (1.2GB)          │
│ VM55                                   Network 0/ip     10.1.0.4             │
│ VM66                                   Network 0/ipv4/0 10.1.0.4             │
│ VM777                                                                        │
│ VM888                                                                        │
│ VM9999                                                                       │
│ VM10000                                                                      │
│ VM11000                                                                      │
│ XOA                                                                          │

│ Virtual Machines                       Host Performance Information          │
│                                                                              │
│ VMs Running On This Host               CPU Usage        35% of 4 CPUs        │
│ Host Performance Information           Memory Usage     72% of 23GB          │
│ All VMs                                                                      │

│ All VMs                                XOA                                   │
│                                                                              │
│ VM1                                    Power State      Running              │
│ VM222                                  Memory           2.0GB                │
│ VM333333                               CPU Usage        0% of 2 CPUs         │
│ VM4                                    Memory Usage     62% (1.2GB)          │
│ VM55                                   Network 0/ip     10.1.0.4             │
│ VM66                                   Network 0/ipv4/0 10.1.0.4             │
│ VM777                                                                        │
│ VM888                                                                        │
│ VM9999                                                                       │
│ VM10000                                                                      │
│ VM11000                                                                      │
│ XOA                                                                          │

2. In 8.0.0:

│ VMs Running On This Host               XOA                                   │
│                                                                              │
│ XOA                                    Power State      Running              │
│                                        Memory           2.0GB                │
│                                        CPU Usage        <Unknown>            │
│                                        Memory Usage     <Unavailable>        │

│ Virtual Machines                       Host Performance Information          │
│                                                                              │
│ VMs Running On This Host               CPU Usage        <Unavailable>        │
│ Host Performance Information           Memory Usage     <Unavailable>        │
│ All VMs                                                                      │

│ All VMs                                XOA                                   │
│                                                                              │
│ someVM                                 Power State      Running              │
│ someotherVM                            Memory           2.0GB                │
│ someotherotherVM                       CPU Usage        <Unknown>            │
│ someelseotherVM                        Memory Usage     <Unavailable>        │
│ XOA                                    Network 0/ip     10.1.0.12            │
│                                        Network 0/ipv4/0 10.1.0.12            │

Could you restore displaying these pieces of information in xsconsole, please, please?

flatlinebb Hmm..., it's present here. XCP-ng Center version 8.0.1 (build 8.0.1.26) 64-bit. Windows 10.

TodorPetkov said in DR backup between sites:

XOA is pulling the image from S2 and sending it to S3

As far as I understand, the quoted way. At least before an awaited new feature "XO proxy" arrives.

You may want to have a look at a blog post by @Marc-pezin https://xen-orchestra.com/blog/backup-proxies/, especially the image "Backup on remote site (without proxy)".

borzel Do you mean these fresh updates released two(?) days ago?
No, on this host I haven't installed them yet.

Anyway, this is 7.6, the message doesn't mention any particular patch level, just "7.6 and higher"

@Marc-pezin

Hi :-).

I've just updated XOA to 5.36.0. I'm in the "latest" release channel in this installation.

XOA is displaying about an other host:

Hyper-threading (SMT) HT detection is only available on XCP-ng 7.6 and higher

but this is 7.6 and XOA is displaying it on the same page:

Version 7.6.0 ()

Intel(R) Xeon(R) CPU E31220 @ 3.10GHz

Just reporting, I already know the CPU in this particular host has no hyper-threading :-).

stormi I've just done yum update (Complete!) and rebooted.
Seems OK.

Comparing before and after the reboot, the only differences in output of xl dmesg (apart timestamps) are:

<  Detected 3504.246 MHz processor.
---
>  Detected 3504.212 MHz processor.

<   Init. ramdisk: 000000026ee32000->000000026ffff04b
---
>   Init. ramdisk: 000000026ee32000->000000026ffff164

Also, microcodes don't seem to be newer:

# xl dmesg | grep -i microcode
(XEN) [    0.000000] microcode: CPU0 updated from revision 0x8e to 0xb4, date = 2019-04-01
(XEN) [   18.296976] microcode: CPU2 updated from revision 0x8e to 0xb4, date = 2019-04-01
(XEN) [   18.373666] microcode: CPU4 updated from revision 0x8e to 0xb4, date = 2019-04-01
(XEN) [   18.450559] microcode: CPU6 updated from revision 0x8e to 0xb4, date = 2019-04-01

but it's OK, isnt it?

DukeVenator

1. I suppose you've done that, but just in case I'lll ask: have you issued
   systemctl restart xo-server.service
   ?

2. Firewall rules may need modyfying.
   What is the output of ufw status verbose ?

borzel said in XCP-ng Dom0 Clarification question:

LonnieTC as I found out, for PV VMs you can do

• xl list <-- List of xen domains
• xl console <ID> <-- connect to the console of your VM (should just work for PV VMs)

BTW, I had to try to use this method.
Some VMs let me in, other not at all.
All are Hardware-assisted Virtualization (HVM).

jcpt928