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...
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!
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!
I did it that way so as to get the old Citrix driver first, and then let it update and watch it reboot. That was my logic anyway.
@dinhngtu said in Migrating from XCP-ng Windows guest tools to Citrix:
@bberndt Okay, I managed to reproduce your situation. I think it's because the "driver via Windows Update" option was enabled after installing the XS drivers, which caused the drivers to lock onto the non-C000 device and prevent updates from coming in.
Normally, XenClean should be able to fix the situation. But if you want to fix things manually, or if things still don't work (C000 is still not active), here's a procedure that should fix the problem:
- Take a snapshot/backup/etc.
- Keep a note of static IP addresses (if you have any; there's a chance those will be lost). You can also use our script here: https://github.com/xcp-ng/win-pv-drivers/blob/xcp-ng-9.1/XenDriverUtils/Copy-XenVifSettings.ps1
- Reboot in safe mode and disable the non-C000 device.
- Reboot back to normal mode; it'll ask you to reboot a few more times.
- The C000 device should now be active and you should be able to get driver updates again.
- (Optional) You can now enable and manually update the non-C000 device (Browse my computer - Let me pick).
@dinhngtu
says none found, and asks to go to windows update, which says im up to date. Further up in this thread, I tried to recall my exact procedure. I suppose I can't say the group policy isn't doing something, but it just setting the date and time (wednesdays) to run once a week, and the deadline is to reboot Saturdays, 3 days later.
@dinhngtu
Tried to get everyone in the same screen shot here.
the 'older' one has the subtree under it,.
@dinhngtu said in Migrating from XCP-ng Windows guest tools to Citrix:
XenServer PV Bus 9.19.105
Notice the other XenServer PV Bus (C000), this one is the current version compared to Citrix release page. Another test server I set up, and installed the latest Citrix installer 9.4.1, and it has a Xenserver PV Bus (002), and one (C000). We are not using WSUS at all. This is on Server 2019.
@dinhngtu We have a Domain Policy that is intended to update and reboot on a set schedule. I didn't see more drivers in Optional Updates. I don't see Optional Drivers at all, as a section in the Windows Updates panel, maybe because its done in the Policy. I -have- seen this in Windows 10/11.
can you please confirm this is as expected.
Started a new Windows 2019 Eval edition (what I had handy, I assume 2022 is similar)
installed XCP-ng 8.2.2 open source guest tools.
ran windows update to get windows up to date.
Used the xenclean script to remove XCP-ng Tools tools.
Installed Citirx guest tools : Management agent, drivers version 9.4.0; told to NOT update drivers through agent (installed the older one, so as to see it update on its own)
set registry value Autoreboot to 3.
shut down
Set VM to use Windows Update in XO advanced settings.
Started VM
Ran windows update, it found latest drivers. and then -I- rebooted when told to.
Windows booted as expected. Shortly after -it- rebooted again once more
(the '3' is a Max reboot?)
Control panel, software and features still say Xen Tools 9.4.0 (old), but the individual drivers:
XenServer PV Network Device: 9.1.7.65 (old, and current)
XenServer PV Storage Host Adapter 9.1.8.79 (old)
XenServer PV Bus 9.19.105 (old)
XenServer PV Bus (C000) 9.1.11.115 (current)
XenServer PV Network Class 9.1.2.101 (old)
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.
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?
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...