@fohdeesha I just did a reinstall of the interface-rename package to make sure I hadn't changed the shebang in the past, the reinstalled copy declares python3

@stormi I found that the interface-rename script broke with this update due to changes in python, specifically the line where the script concats two dict.keys(): the keys() method signature changed to return dict_keys, which doesn't have the add (or w/e it's named) method, so "a.keys()+b.keys()" fails now. I had to hand-edit the script to get it working, the fix is trivial: concat lists of keys rather than the keys directly.

@fohdeesha I just did a reinstall of the interface-rename package to make sure I hadn't changed the shebang in the past, the reinstalled copy declares python3

@stormi I found that the interface-rename script broke with this update due to changes in python, specifically the line where the script concats two dict.keys(): the keys() method signature changed to return dict_keys, which doesn't have the add (or w/e it's named) method, so "a.keys()+b.keys()" fails now. I had to hand-edit the script to get it working, the fix is trivial: concat lists of keys rather than the keys directly.

@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?")

@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!

A couple of issues in my environment:

1. 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)

2. 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

@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?