@olivierlambert No, the only thing I get with xl dmesg on the host, for some time back, are random brief reports of individual CPUs running above temperature threshold and then being clocked down, and then resolving. Nothing else.

I suppose you mean OVA, right? Anyway, good news

@olivierlambert said in Very scary host reboot issue: I am very very busy so I don't have time to make a search by myself but maybe someone else around with few minutes could point you to the blog post talking about this edit: found it in few sec luckily: https://xcp-ng.org/blog/2024/01/26/january-2024-security-update/ Thanks. I'll check this out.

@James92 Storage Performance: Storage Performance in a single VM on a single disk is very slow on xen compared to hyper-v and vmware. this is because of the single-thread design of tapdisk. so nvme performance on xen will be cpu-core-ghz limited. there are only some workarounds like raid-0 in vm but no general satisfactorily solution. it does not seem that this will change soon.

Indeed, but it's a bit old, and I would say for many reasons HVM with PV drivers is still the way to go for classical server virtualization mode

@Danp I tried some of the xe commands listed in that post like xe vm-param-clear and xe vm-param-remove and wasn't successful.

@tjkreidl Yeah, thanks. 12 hours, 68 VDIs to coalesce down to 10. Quite the improvement.

Interpreting vulnerability scanners is a hard task. They are often screaming for "common cases", but remember XCP-ng is an appliance, so there are many cases where things do not apply. Happy to help you further via our pro support to answer in details your concerns

@Danp So, that's the "best" way? Backup the meta-data with XOA, rebuild the OS drive - add the "new" server into XOA and restore the meta-data back to the new install? (I'm not doubting it is, just wanting to be sure we're understanding each other fully.) Seems straight-forward - but there's a ton of things I've done over the years that "seemed" pretty straight-forward that turned out to be anything but, and at least occasionally found I had no way back.

@mmancina Hi you can try to call xe pif-scan host-uuid=<uuid of your host> , the NIC should appear after that.

Spoke too soon. Still getting them... Just much slower and father apart.. about 5-10 a day

@bleader No, the opnsense box itself doesn't have wireguard (or anything else VPN-ish) running on it. It's mostly just a NAT with the normal variety of DHCP, DNS, ... services running on it.

@Dataslak said in After installing updates: 0 bytes free, Control domain memory = 0B: @nikade @olivierlambert @stormi @Danp @yann Just wanted to say to you all: Thank you for your contributions and kind helpful assistance which has helped me through this crisis. I would have been in deep trouble without you. I respect your expertise, and appreciate deeply that you are working so hard to help us dumb users. I have learned a lot, and hope one day to become skilled enough to at least help other new users on this forum. Best wishes Aslak Happy everything worked out, this is what this community is all about. I've gotten a lot of help and given some too, it's all about helping out with the things that you can. With time you'll be able to help out more and more and more

Using dynamic memory is known to be prone to causing occasional issues. Thanks for the feedback. Oh, by the way, regarding vTPM and snapshots, we finally established that it's fully supported by XenServer 8 and that the documentation was just out of date.

Hi, It's not possible.

Hi, No.

Right, so yeah I did just that - disabled HA and have been keeping an eye on the logs as well as general performance in the env. Glad to know my actions align with your recommendations at least There are a couple of hosts that get a lot of these sorts of messages in the kern.log: Apr 25 08:15:33 oryx kernel: [276757.645457] vif vif-21-3 vif21.3: Guest Rx ready Apr 25 08:15:54 oryx kernel: [276778.735509] vif vif-22-3 vif22.3: Guest Rx stalled Apr 25 08:15:54 oryx kernel: [276778.735522] vif vif-21-3 vif21.3: Guest Rx stalled Apr 25 08:16:04 oryx kernel: [276788.780828] vif vif-21-3 vif21.3: Guest Rx ready Apr 25 08:16:04 oryx kernel: [276788.780836] vif vif-22-3 vif22.3: Guest Rx ready Am I wrong to attribute this to issues within specific VMs (i.e. not a hv performance issue)? I know one of the VMs that causes these is a very old centos 5 testing VM one of my devs use and the messages stop when it's powered down. Is there any way to easily associate those vifs with the actual VMs they are attached to? My google-foo failed me for that. Other than that, I noticed my nic firmware is a bit old on the X710-da2's I use so I'm going through and upgrading those with no noticeable changes. I'm fairly hesitant to re-enable HA without tracking down the root cause.