Updated xcp-ng-pv-tools on my one XCP 8.2 server. (We have mostly (citrix)7.1 and (xcp)7.6 because of hardware RAID limitations)
Found the ISO located at /opt/xensource/packages/iso. (verison 8.2.0-9)
Moved this to my local workstation, and then to my ISO-repo file server.
Went to my XCP 7.6 server, and then to the Rocky Linux 8.4 VM i just set up.
Removed the EPEL xe-guest-utilities-latest package. (7.21.0-1)
Mounted the XCP ISO from the ISO-repo and installed the guest tools from that. (7.20.0-9)

Agent detected! and the service seems to run without error.

.51 for Rocky showed up today. Running my first test. and from .22.

Seems successful!

Updated to Master build, a66ae, xo-server 5.92.0, xo-web 5.96.0.
Consoles seem to work fine again.
thanks all!

@florent
I ran the install upgrade script from @ronivay with the fix_console_proxy_xcp_7x branch. Seems to be working.

Can't create Private Network, on XO 5.83

I got to the Pool page, and select Network tab, and then, Select Manage. Add a network, and then hit the Private button. It makes me select a PIF, but anyone I select, and hit go, gives me an error.

I've seen instructions, and they seem pretty easy, so not sure what im doing wrong here.

Doing so in XCP-Center worked fine.

sdnController.createPrivateNetwork
{
  "poolIds": [
    "8e059584-1d7b-b674-1fe4-ef5cd08d2550"
  ],
  "pifIds": [
    "566e0925-72d9-f3c3-6c06-b05ab7035018"
  ],
  "name": "dfg",
  "description": "dfg",
  "encapsulation": "gre",
  "encrypted": false
}
{
  "message": "no connection found for object 8e059584-1d7b-b674-1fe4-ef5cd08d2550",
  "name": "Error",
  "stack": "Error: no connection found for object 8e059584-1d7b-b674-1fe4-ef5cd08d2550
    at default.getXenServerIdByObject (file:///opt/xo/xo-builds/xen-orchestra-202111011545/packages/xo-server/src/xo-mixins/xen-servers.mjs:197:13)
    at default.getXapi (file:///opt/xo/xo-builds/xen-orchestra-202111011545/packages/xo-server/src/xo-mixins/xen-servers.mjs:478:29)
    at default.getXapiObject (file:///opt/xo/xo-builds/xen-orchestra-202111011545/packages/xo-server/src/xo-mixins/xen-servers.mjs:484:17)
    at Xo.getXapiObject (/opt/xo/xo-builds/xen-orchestra-202111011545/node_modules/lodash/_createBind.js:23:15)
    at map (/opt/xo/xo-builds/xen-orchestra-202111011545/packages/xo-server-sdn-controller/src/index.js:716:46)
    at Array.map (<anonymous>)
    at SDNController._createPrivateNetwork (/opt/xo/xo-builds/xen-orchestra-202111011545/packages/xo-server-sdn-controller/src/index.js:716:27)
    at Object.call (/opt/xo/xo-builds/xen-orchestra-202111011545/packages/xo-server-sdn-controller/src/index.js:363:12)
    at Api.callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202111011545/packages/xo-server/src/xo-mixins/api.mjs:304:33)"
} 

pulled and rebuilt and plugins have returned!

Hello.,
Some backstory:
Most of out VMs us the 8.2.2. XCP-ng guest tools in Windows. These have been rock solid, probably because there are not updates for it.

Some VMs for whatever reason, depending on the method, and what the Human Admin is used to, end up with the Citrix device drivers. We've noticed that when this happens, and they go to update, it really hoses the VM. Its constantly rebooting several times, and needs a user to log in, get the message that it needs a reboot, and then reboot, at least a couple times. Often its completely offline, and an Admin needs to get on the VPN, log in to XO or XCP-center, and go to the VM console, and reboot, and or put the IP information back in to a new virtual ethernet interface.

In fact this happened last night, despite the Scheduled Task in windows set to disable, and the "get from Windows Update" set to OFF, the Citrix Guest drivers needed an update, and the VM was offline for a while. (the problem being this particular VM is required to be up for the VPN to work. So an Admin had to come to office, and get into the VM console. and reboot several times.)

1. What might we be missing? why do the Citrix drivers behave so badly at updates?

2. I see that there are recent updates to the XCP-ng drivers, that are here, and or coming, depending on MS. Thus this brings up my next question, and reason for reaching out.

3. Im hesitant to migrate to the Citrix drivers because of this. (Or even the newer XCP-ng drivers, if they are going to update the same way) The last thing I need is an Human Admin babysitting 130 VMs every patch Tuesday, or more. Especially when the other Admin is a staunch Hyper-V fan

Any suggestions would be helpful.
thanks.

.51 for Rocky showed up today. Running my first test. and from .22.

Seems successful!

@Greg_E said in XCP vm fails to boot after newest kernel applied.:

@bberndt

This may sound stupid, but here goes...

Does Rocky need to update to .50 before it can update to .51?

I'd guess no, but I've been away from RHEL based stuff since the IBM rug pull. Only coming back because I may need it in the future as I jockey around trying to improve my paycheck.

https://bugs.rockylinux.org/view.php?id=9307
so, prolly soon-ish.

@Greg_E said in XCP vm fails to boot after newest kernel applied.:

@olivierlambert

I just updated an Alma 8 and it has the .51 kernel now.

Tried one of my Rocky's and still .50. I wonder where we can see the status of downstream fixes like that? anyone know? thanks.

@Greg_E
I made a free account.
Resolution
The issue has been resolved with the errata: RHBA-2025:4337. Hence, update the kernel to kernel-4.18.0-553.51.1.el8_10 to fix the issue.

id assume it arrives soon? I as well, haven't seen it yet.

@Greg_E said in XCP vm fails to boot after newest kernel applied.:

@bberndt

Ok, that might explain the difference.

Would a LEAPP from Rocky 8 up to Alma 9 be possible and solve the issue?

I did a (not LEAPP, but a migration script from Alama) from Rocky 8 to Alma 8, and it died. None of my Rocky 9's have had a problem so far, and of course end up with a completely different kernel.

@Greg_E said in XCP vm fails to boot after newest kernel applied.:

@bberndt

If I find an hour, I'll give Rocky 8 a try.

Could you use LEAPP to migrate that to Alma, maybe they are doing something differently which is why mine are working.

I can tell you, there is nothing special that I'm doing, my systems are as vanilla as they get.

@Greg_E
google AI says what I think is familiar:
Rocky Linux strives for 1:1 bug-for-bug compatibility with RHEL, while Alma Linux is more of an RHEL rebuild, making some adjustments and adding its own features

@Greg_E said in XCP vm fails to boot after newest kernel applied.:

@bberndt

Is there something different about Alma? Friday I may have some time to fiddle and can try a Rocky 8 to see what happens.

Is this an 8.2 and 8.3 issue or just 8.2? I have 8.2 in production and could try there, 8.3 in my lab with a very fresh build.

Migrated to a XCP-ng 8.3 host. Xeon E5-2689 v4
No change.

@Greg_E said in XCP vm fails to boot after newest kernel applied.:

@bberndt that's why I mentioned uefi, wondering if legacy is part of the problem. I won't have time to fiddle with this for a while, broke a couple things today that I need to fix, and need to set up glpi for some testing.

Made a new Rocky Linux 8 install, on a lab host. UEFI boot mode, and mostly all defaults. on XCP-ng 8.2 on a E5 2620 v0 host.
Used the guest tool from the Rocky and or EPEL repository. (added the EPEL repo and then installed xe-guest-utilities)
Does NOT boot after updating to the latest kernel.

@Greg_E
I checked a few of mine, and they appear to all be BIOS mode. not UEFI.
I've had a couple hardware machines as well, that updated OK. I know at least one was UEFI.