Categories

  • All news regarding Xen and XCP-ng ecosystem

    139 Topics
    4k Posts
    M
    @uberiain at this point, when I am uninstall the old XCP-ng center software, and install the new msi, I just realized the xcp-ng keeps the settings file in Roaming folder. (C:\Users\user\AppData\Roaming\XCP-ng) When I deleted it I could re-register the servers.

  • Everything related to the virtualization platform

    1k Topics
    14k Posts
    N
    @bvitnik I'm having a hard time figuring out if you're trying to be helpful, so I'm going to assume you are. All of my USB disks are data disks. Xcp-ng can boot just fine without them attached. My OS runs on an NVMe and a hardwired SSD with software RAID 1 (through xcp-ng). So yes, this issue initially began as a USB issue, but that's definitely not related to why I'm unable to boot now. In fact, the USB disks have been fully disconnected during all of my troubleshooting so as not to disturb them (or their data) accidentally.

  • All Xen Orchestra related questions/reports

    3k Topics
    26k Posts
    B
    I get the following error when I try to migrate a VM to another host. I'm selecting Storage10g as the migration network and both hosts have this network configured. [image: 1763776436483-2025-11-21-17_50_44.png] [image: 1763776447064-2025-11-21-17_50_23.png] vm.migrate { "vm": "1a0672e4-cd08-a217-5403-7e18b237f296", "migrationNetwork": "cd1d0820-5fd6-2d79-ab12-1c3e92f06c2d", "sr": "ab9780b1-fcdc-7ea4-395a-5369bd6024c5", "targetHost": "05081ef2-b594-4a62-9b8b-c4a7bc903323" } { "code": "VM_REQUIRES_NETWORK", "params": [ "OpaqueRef:c3355c6b-773e-64a4-fe63-ebbd6aa68686", "OpaqueRef:eb6eb456-cb99-4439-b7d0-a5dc282ae52b" ], "task": { "uuid": "6e008922-6846-e081-50d0-fef98f6dee5b", "name_label": "Async.VM.assert_can_migrate", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20251122T01:47:47Z", "finished": "20251122T01:47:47Z", "status": "failure", "resident_on": "OpaqueRef:1e3c6744-f007-4357-8c83-b3e46db7ef53", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "VM_REQUIRES_NETWORK", "OpaqueRef:c3355c6b-773e-64a4-fe63-ebbd6aa68686", "OpaqueRef:eb6eb456-cb99-4439-b7d0-a5dc282ae52b" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [], "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_network_attach_helpers.ml)(line 174))((process xapi)(filename ocaml/xapi/xapi_vm_helpers.ml)(line 705))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 1812))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2547))((process xapi)(filename ocaml/xapi/rbac.ml)(line 229))((process xapi)(filename ocaml/xapi/rbac.ml)(line 239))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))" }, "message": "VM_REQUIRES_NETWORK(OpaqueRef:c3355c6b-773e-64a4-fe63-ebbd6aa68686, OpaqueRef:eb6eb456-cb99-4439-b7d0-a5dc282ae52b)", "name": "XapiError", "stack": "XapiError: VM_REQUIRES_NETWORK(OpaqueRef:c3355c6b-773e-64a4-fe63-ebbd6aa68686, OpaqueRef:eb6eb456-cb99-4439-b7d0-a5dc282ae52b) at Function.wrap (file:///opt/xo/xo-builds/xen-orchestra-202511102201/packages/xen-api/_XapiError.mjs:16:12) at default (file:///opt/xo/xo-builds/xen-orchestra-202511102201/packages/xen-api/_getTaskResult.mjs:13:29) at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202511102201/packages/xen-api/index.mjs:1073:24) at file:///opt/xo/xo-builds/xen-orchestra-202511102201/packages/xen-api/index.mjs:1107:14 at Array.forEach (<anonymous>) at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202511102201/packages/xen-api/index.mjs:1097:12) at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202511102201/packages/xen-api/index.mjs:1270:14)" }

  • Our hyperconverged storage solution

    37 Topics
    690 Posts
    ronan-aR
    @TestForEcho No ETA for now. Even before supporting QCOW2 on LINSTOR, we have several points to robustify (HA performance, potential race conditions, etc.). Regarding other important points: Supporting volumes larger than 2TB has significant impacts on synchronization, RAM usage, coalesce, etc. We need to find a way to cope with these changes. The coalesce algorithm should be changed to no longer depend on the write speed to the SR in order to prevent potential coalesce interruptions; this is even more crucial for LINSTOR. The coalesce behavior is not exactly the same for QCOW2, and we believe that currently this could negatively impact the API impl in the case of LINSTOR. In short: QCOW2 has led to changes that require a long-term investment in several topics before even considering supporting this format on XOSTOR.

  • Non-English speakers

    30 Topics
    85 Posts
    GlitchG
    @Davidj-0 Merci pour le retour, j'utilisais aussi une Debian pour mon test ^^