Adding @lsouai-vates in the convo

@florent said in mirror backup to S3: @robyt your doiing incremental backup with 2 step : complete backup ( full/key disks) and delta (differencing/incremental) Both of theses are transfered through an incremental mirror on the other hand if you do Backup , it build one xva file per VM containing all the VM data at each backup. These are transfered through a Full backup mirror we are working on clarifying the vocabularyahhhh... the full mirror to S3 is not necessary

Question for @florent

I think whatever solution suits you will work. Personally, if I know there are issues with it, I would tend to disable it in the bios, to be sure nobody tries to use it later and waste their time, in a enterprise settings, that can be important. One thing to keep in mind if keeping it, is that if you want to add other hosts to the pool, they will need to have similar network topology, so if you endup having eth0 and eth1 with your current management network on eth1, any new host should be able to have its management on eth1 as well. You may work around it with interface renaming, but that tends to get messy over time. That being said, I'm unsure even removing the realtek nic from the bios will change the interface number now that eth1 exists already and is configured. If you don't plan to add hosts to the pool, and don't have a team with people that may act on these machines in the future without being aware of this setup history, leaving it connected and disabling the port on switch should not be an issue.

@johnny I think the Vates VMS (whether you go with paid support or not) would fit your use case perfectly. Since each host is essentially a pool of one, you would pretty much have multiple pools managed by a single Xen Orchestra instance (giving you a single pane of glass, if you will). You could augment this with XCP-ng Center. As @olivierlambert correctly inquired, you should contact the Vates Team and have an in-depth discussion into your situation.

Hello, I tried on a new pool. a little different scenario since i don't create xostor for now, on my previous example, i tried to add a node as replacement of an existing one.. I just run the install script only on node 1. When i try make node2 join the pool, i reproduce the incompatible sm error i got previously. The things which is "bizarre", is i don't have the license issue i got on Xen-orchestra. ( maybe it was finally not related ? ) Here is the complete logs. pool.mergeInto { "sources": [ "17510fe0-db23-9414-f3df-2941bd34f8dc" ], "target": "cc91fcdc-c7a8-a44c-65b3-a76dced49252", "force": true } { "code": "POOL_JOINING_SM_FEATURES_INCOMPATIBLE", "params": [ "OpaqueRef:090b8da1-9654-066c-84f9-7ab15cb101fd", "" ], "call": { "duration": 1061, "method": "pool.join_force", "params": [ "* session id *", "<MASTER_IP>", "root", "* obfuscated *" ] }, "message": "POOL_JOINING_SM_FEATURES_INCOMPATIBLE(OpaqueRef:090b8da1-9654-066c-84f9-7ab15cb101fd, )", "name": "XapiError", "stack": "XapiError: POOL_JOINING_SM_FEATURES_INCOMPATIBLE(OpaqueRef:090b8da1-9654-066c-84f9-7ab15cb101fd, ) at Function.wrap (file:///etc/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12) at file:///etc/xen-orchestra/packages/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:60:5) at processImmediate (node:internal/timers:454:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" }```

@fanuelsen I was having a similar problem just now with XCP-NG 8.3 LTS and the latest XO. I was unable to migrate an MCS-created VM using XO (I was doing a Host Migrate within the pool only; no storage migration). Oddly, I was able to do the Host Migration using XCP-NG Center. This was in a production Pool that I had recently set up, and this time I had been given a dedicated 10Gbps team with VLANs for migration and host management, and two separate 10Gbps teams for storage and for VMs, respectively. To get live migration of my MCS-created VMs to work, I had to delete the Default Migration Network on the Pool's Advanced tab. I don't see a downside to doing this as all my NICs are 10Gbps, so all NICs should operate at roughly the same speed.

@TrapoSAMA All of mine are 2022, but saw this in previous driver versions with 2025. Low priority on this so I haven't fixed it yet.

@afk said in What is the status/roadmap of V2V (Migrating from VMware to XCPng/XO) ?: Great news ! Thanks @olivierlambert and @florent and let me know if you need some information on the vmware side. yes we are prototyping with vddk , it should open some interesting possibilities. stay tuned, hopefully by the end of the summer (I am saying it again : for a prototype) as a shameless plug, we are looking for users with VSAN to ensure we don't break thing for it

Since I updated 'everything' involved yesterday, the problems remain (this night's backups failed with the similar problem). As I'm again 6 commits behind the current version, I cannot create a useful bug report, so I'll just update and wait for the next scheduled backups to run (nothing the night towards Thursday, the next sequence will run at the night towards Friday)

@olivierlambert Yes sir, it is and I'm glad I confirmed this for myself. Thanks also for helping me understand how the VM Suspend process works. Hopefully this post helps other newbies with the same understanding in the future.

Thank you @florent. I'll do that. Update: It worked.

Have you checked: https://docs.xcp-ng.org/troubleshooting/common-problems/#tcp-segmentation-offload-tso-decreasing-performances https://docs.xcp-ng.org/troubleshooting/common-problems/#tcp-segmentation-offload-tso-decreasing-performances And for Pfsense: https://docs.xcp-ng.org/guides/pfsense/#3-disable-tx-checksum-offload

@HH said in XO Commuity Edition Xen Orchestra, commit fee7b geht nicht auf Master, commit e5702: I didn't mean that I want to go to 6.0 now, but when 6.0 becomes "Stable LTS", get that automatically with your script ? Assuming there aren't any major changes to the upgrading processing using the existing script should work, but that has to be determined once a general release is created.

@knightjoel Thanks for the suggestion. Since my original message, I've tried moving my allow rule to the top, before any Deny rules, after any deny rules, I even tried experimenting with commenting all of the deny rules to see if any of those would make a difference; unfortunately none of them made a difference. I've tried simply saving the file then initiating a xe pusb-scan on the host, I also tried rebooting to see if that would have an effect, but it doesn't seem to.

Hmm I'm not sure it's even possible due to the nature of isolation provided by Xen Let me ask @Team-Hypervisor-Kernel

@olivierlambert You got it, I'll do that. Thank you.

Hello. @JamfoFL said in Xen Orchestra from Sources unreachable after applying XCPng Patch updates: This is very odd. When I check to see if the Orchestra status is running, everything looks OK: [image: 1752072112055-5c529c8c-8f2b-4c79-806c-daa2b8398847-image.png] This doesn't look ok. The process behind this service has actually exited. Suggest you start/restart this service and check if XO is reachable. If it's not, dive into the logs and look for clues why the process is exiting. You may want to also try manually running /etc/init.d/orchestra and see if that produces any helpful output. But when I try to run the command you sent over, I get an error message stating "Unit xo-server.service" could not be found". However, when I check in the very same folder from which I am running the command, I can see xo-server.service right there. Not taking away from the points others have made about .service files needing to be in the correct location, but in your case, worrying about the xo-server.service file is probably a dead end. It appears whoever installed XO created the systemd service as orchestra. You needn't try and "fix" the fact you don't have an xo-server.service. .joel