XCP-ng 8.3 beta 🚀
-
after last bunch of updates via XO and toolstack restart, maintenance mode not disabled automaticaly.
going fine after reboot. -
@stormi said in XCP-ng 8.3 beta :
@xerxist said in XCP-ng 8.3 beta :
Which kernel are you looking at since 4.19 will be EOL in 9 months?
So, the main blocker in the way to upgrade the kernel is a kernel module we use for storage access from the VMs.
I'm curious: which module?
-
A couple of issues in my environment:
-
Stats are still broken for me, even after ensuring XO was updated (from source) and that the latest patches were applied to my pool. Was there a public GH issue tracking this breakage? (I hope to use the issue to track back to the code to find out why and see if there's something unique about my environment that might be the cause)
-
I know pure PV VMs are entirely unsupported, so I don't expect this to go anywhere, so no big deal if this remains broken (for me anyways!) but after the latest updates XAPI throws "shadow_allocation_set ${sz}MB invalid argument" (where ${sz} depends on static memory config for that VM) when I try to start a PV VM. To the best of my understanding, shadow pages are only supported for HVM, right?
Thanks!
Kevin -
-
@r0ssar00 You should convert PV VMs to HVM. However, if you really can't, you can switch them from
pv
topv-in-pvh
. It's not documented yet but this blog post will give you an example: https://xcp-ng.org/blog/2022/01/17/removing-support-for-32-bit-pv-guests/ -
@r0ssar00 Regarding broken stats, you could try to find logs related to them. Failures related to "stat" or "rrd" keywords, possibly. There was no github issue opened, so most details about the issue others had will only be found in this thread.
-
@r0ssar00 Could this be your issue with missing stats?
If statistics (all VMs and hosts) are not showing for a specific pool, check if there is a Backup network configured on your pool (setting is in the Advanced tab of the pool) and make sure XO can access all hosts of the pool via this network.
-
@Danp this was exactly it, thanks! Although I'm 100% sure the network is accessible to both hosts (they're directly connected to each other, no switch in between, ping to/from hosts/VMs-on-either-host works just fine), clearing it resolved the problem. I tried the other two networks I have set up (one is directly connected, one goes through a switch and is shared with the rest of my LAN) and only using the primary management interface worked (which kinda defeats the purpose...).
If this strikes you as a bug, happy to collect logs/etc, just let me know what and (a pointer to) how!
-
@stormi My inner "I want to do something slightly off the beaten path" nerd will be disappointed, but that's really all this was, just trying something different to be different for the challenge. Just thought I'd note it since it's not outside the realm of possible (in my mind anyways) that this is a symptom of potentially incomplete code ("failing to handle or improperly handling a config value" -> "is this the only place that happened?")
-
I have a suggestion w.r.t interface-rename.
Can we have a screen at the installation (using iso method) which lists all the NICs and we can rename the interfaces at install time itself ?