removed the failed server connection.

Restarted xo-server service.

Added new host again. Seems fine now.

In hind sight, I could have very well recycled a DHCP ip here as well, if that is a known issue...

A couple Windows 2016, and 2019, and a couple Rocky Linux 8 is what Im moving.

I'll see if I have an 8.2 host suited (not too different CPU) to be a middle man.

thanks.

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!

Will have to think more on this. We do have a a domian policy for Windows Updates, that mostly works; it never seems to work as intended. In any case, if a Citrix driver is updated, with the registry setting set, it will reboot x number of times? (3 is suggested I believe)
Wish there was a bomb proof method. Just this morning I came to office to find half the building down, because MS decided to push a Citrix update last night, and the DHCP server was down, until I rebooted the VM from the console once more. ;(

@dinhngtu Excuse the dumb questions
When we use the XCP-ng tools, 8.2.2, There are no unexpected reboots, I -thought- because they weren't updating by themselves, and have had zero problems. We have a ISO with these, that we load on most of out VMs, and never have problems.
Others, for whatever reason,. (admin-user forgets the Get drivers from Windows Update setting, etc), reboot unexpectedly, and on occasion are down, like I mentioned earlier, until someone logs into console and set up new ethernet interface in the VM.

Im thinking of what to do in our environments, but currently leaning on letting Windows Update do it, and setting the reboot setting to 3 or so. (not ideal, we have 1 particular host that is very i/o deficient) We'd be rebooting for Updates anyway, and a real machine would get driver updates then anyway. Can you confirm this might be a good way to do it, or some other suggestion. (that I'd need to use to form my own ideas, for us )
Or hold out for the new XCP-ng drivers. Not sure how long I should do that though.

@dinhngtu Couple more questions I thought of.

1. When the setting in XO "get drivers from Windows Update", they are only updated when something is published from Citrix, -and- my normal Windows update procedure takes place? Otherwise, probably the same as what ever i'd installed from a Citrix ISO, or installer, and -that- would have its own update schedule separate from Windows Update?

2. Presumbly when the XCP-ng guest tools/ device drivers are finally signed (any time frame on that?) they would NOT be getting updates like the previous 8.2.2? Or are they now going to update on some schedule?

thanks.

removed the failed server connection.

Restarted xo-server service.

Added new host again. Seems fine now.

In hind sight, I could have very well recycled a DHCP ip here as well, if that is a known issue...

found a similar machine that was testing some XCP-ng 8.3 stuff on it.
Re-installed 8.2
Now can't add to XO at all. All I can find for people with this error is adding a host thats already in a pool. In this case, there are no pools.

hrm.

server.enable
{
  "id": "a6cce2cd-f3c8-[redacted]-2bfce24a6d96"
}
{
  "poolId": "b5a4db02-f996-[redacted]-7ed3cad86788",
  "connectedServerId": "f1f0aa28-f820-[redacted]-7c15c1686461",
  "connectingServerId": "a6cce2cd-f3c8[redacted]-2bfce24a6d96",
  "message": "this pool is already connected",
  "name": "PoolAlreadyConnected",
  "stack": "PoolAlreadyConnected: this pool is already connected
    at XenServers.connectXenServer (file:///opt/xo/xo-builds/xen-orchestra-202505021422/packages/xo-server/src/xo-mixins/xen-servers.mjs:358:15)
    at Xo.enable (file:///opt/xo/xo-builds/xen-orchestra-202505021422/packages/xo-server/src/api/server.mjs:121:3)
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202505021422/@vates/task/index.js:175:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202505021422/@vates/task/index.js:159:20)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202505021422/packages/xo-server/src/xo-mixins/api.mjs:469:18)"
}

A couple Windows 2016, and 2019, and a couple Rocky Linux 8 is what Im moving.

I'll see if I have an 8.2 host suited (not too different CPU) to be a middle man.

thanks.

I'll post the error below. Im using XO Xen Orchestra, commit 80e72
Master, commit 48603, from sources which I update form time to time.

Im trying to migrate sme VMs from XCP 7.6 to a different host that has 8.3 on it. Keep getting errors. I can migrate from a XCP 8.2 to the same destination I want, in the error. And from the 7.6 to 8.2.

is 7.6 and 8.3 too big a jump for XO? or am I a little far old and need an update? And XCP Center doesn't connect to XCP 8.3

xo_error.txt

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.