Hi, Yes, by default, adding a new host to a pool, it will be lowered on CPU features to the common denominator, in other word, cutting that's not common between all pool members. So: If you add a more recent CPU to an existing pool, the CPU won't use new CPU features If you add an older host to a pool, it will lower down all features from existing CPUs

Hi, You might have a discrepancy between the IP you use to connect and the internal IP reported by XCP-ng, so likely your XO is trying to connect the console via a different IP (the old ones?)

@ph7 worked, ty.

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. ;(

@DwightHat I am using xoa from sources and i updated it to the latest commit which seemed to fix it for me..

@icompit Hello, thanks for the report. I am asking XO Team... @florent FYI

About the xsconsole: sometimes it's not refreshing. You can try to get access to the console, then type "xsconsole" it will start it and you should see it works You must have the master up to date if you want your slave to connect again. I never tried to elect a new master in the middle of the upgrade, I would discourage it. Better shutdown some VMs on the master, upgrade it and you are automatically back on track.

Hi, It was never meant to be a 2 ways synchronization plugin. Making it 2 ways considerably raise the complexity of such plugin (because we would need to make configuration for decision on when to take it one way and the other, and each use case is different). I would say: you shouldn't have any IP that's already in Netbox from other source in the IP range that's used for your VMs.

@JBlessing as it looks like it does start, it looks like the networking side is working, at least at first. Just for debugging purpose you could try to switch that VM to BIOS instead of UEFI if it is possible, maybe it is related to what the pxe is starting in the VM. You could also try switching the VM between realtek and e1000 NIC, at this stage, PV drivers are not there so it is using an emulated NIC, maybe the image your PXE starts doesn't like the one you're using and it gets stuck somehow. As you're already using it with vmware, I assume you know how to size your VM, but if you went for a tight RAM value for this VM, you could try to give it more RAM to see if that could be related, as everything has to fit in RAM at some point, we may be using more at startup than vmware… Hope one of this can help

@Niall-Con Thank you! I'll take a look to that and will ping you to test on real hardware. Just need to find time (in the middle of storm right now), so it'll take one or two weeks most probably.

@robyt 2 is generally a sweet spot

Sorry I forgot to publish in here the news: https://xcp-ng.org/blog/2025/06/16/xcp-ng-8-3-is-now-lts/ Indeed, since June the 16th, XOSTOR is available on 8.3

@blackliner said in Sdn controller and physical network: @nikade How do you "pair" the XCP-ng SDN with your routing setup? You cant/dont, you'll have to setup each private network on the vyos router and then have the vm private network routed through it manually. For example if you have private network 1 with subnet 192.168.1.0/24 you'd have to add this network to the vyos router and assign 192.168.1.1/24 on the router. Then set 192.168.1.1 as default gateway in your vm's which uses this network. Then you'll setup ospf or bgp on the vyos router manually with your upstream border/core-router or firewall. If the subnet is a private subnet you'll need to setup NAT as well somewhere before it reaches internet to NAT traffic from 192.168.1.0/24.

@kagbasi-ngc You are welcome.

@olivierlambert @nathanael-h @Team-DevOps Please let me know if you have answers for any of the flollowing questions: Why JSON-RPC over websocket regularly returns not expected result for calls and what could be done with it? examples: method xo.getAllObjects sometimes returns empty result, but following: jsonrpc method params ------- ------ ------ 2.0 all @{type=enter; items=} On retry - everything is fine and we have all data jsonrpc result ------- ------ 2.0 @{bbdb1ed0-4c86-24ec-...=;..... method vm.copy sometimes returns only task with name_label host.get_server_certificate and no task async.vm.copy. Meanwhile copy operation is started in XEN Orchestra, so we have to separately search for the task currently running in all objects and if it is not there anymore suggest that it completed successfully. Afterwards we need to check if vm was copied and appeared in all objects. That is really frustrating as we have no info about successfully completed tasks in XEN - records just removed as nothing happen. most likely this happens due to other tasks being popped up in tasks at the same time and websocket call recives not its own responce, is it possible to workaround? What is correct syntax for JSON to run job.create method? Are there any article with supported methods for JSON-RPC calls and examples to use them? Calling for "system.getMethodsInfo" I can see "job.create": { "description": "Creates a new job from description object", "params": { "job": { "type": "object", "properties": { "userId": { "type": "string", "optional": true }, "name": { "type": "string", "optional": true }, "timeout": { "type": "number", "optional": true }, "type": { "type": "string" }, "key": { "type": "string" }, "method": { "type": "string" }, "paramsVector": { "type": "object", "properties": { "type": { "type": "string" }, "items": { "type": "array", "items": { "type": "object" } } }, "optional": true } } } }, "permission": "admin" }, But it is unclear what values should I provide to paramsVector and looking into the job created manually (in web interface) with method job.getall I can see 2 jobs [ { "type": "call", "name": "copyvm", "key": "generictask", "method": "vm.copy", "paramsvector": { "type": "crossproduct", "items": [ { "type": "set", "values": [ { "name": "nevm", "vm": "GUID", "sr": "GUID" } ] } ] }, "userid": "GUID", "id": "GUID" }, { "method": "vm.copy", "key": "vm.copy", "name": "copyvmjob", "type": "call", "userid": "GUID", "id": "GUID" } ] How can I create similar job myself if it is not possible to find out why vm.copy does not return async.vm.copy task info?

Release v2.1.0 This new version builds on the improvements to the Terraform Provider regarding the disk lifecycle of a VM (TF provider release). Full Release Note: https://github.com/vatesfr/pulumi-xenorchestra/releases/tag/v2.1.0

Hello, I am asking XO team.

Mine was working on the latest commit however tonight due to a power failure my XO VM rebooted and now i too am experiencing the same errors. My hosts also rebooted as a result. Rolled back to a build from earlier this month and all is well again.