Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    J
    Installed on 3xDell PowerEdge R350 in HA. And so far, I haven't noticed anything out of the ordinary.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    J
    First of all. Thanks for putting alot of effort into getting migrations to work without VDDK. https://github.com/vatesfr/xen-orchestra/pull/10421 However. I did a new provisioning of an XO-source instance. And wanted to test it without any hanging dependencies from previously installed vddk's. Now I'm getting met with failed import-attempts. Attempts with my previous XO instance, on the same commit: b59c8 works just fine. Except the VMs not starting automatically after import (discussed in separate thread: https://xcp-ng.org/forum/post/108686) vm.importMultipleFromEsxi { "concurrency": 2, "host": "vcenter-host", "network": "72471fb1-58fd-d2d1-9a1e-46aea05374b4", "password": "* obfuscated *", "sr": "4d58d7f1-087a-bc7b-a957-e8f8be8b1f77", "sslVerify": false, "stopOnError": true, "stopSource": true, "template": "37e7a3b9-8c45-c7f2-7d09-249a935dd33d-1a647cf9-99c1-4e9c-b3b4-6b9989c530be", "user": "obfuscated", "vms": [ "vm-1169935" ] } { "succeeded": {}, "message": "stream has ended without data, was looking for 8 bytes", "name": "Error", "stack": "Error: stream has ended without data, was looking for 8 bytes at readChunkStrict (/opt/xen-orchestra/@vates/read-chunk/index.js:83:13)" } ´´´
  • 3k Topics
    29k Posts
    J
    @acebmxer said: @john.c We currently dont use ipv6 internally. No network changes were made at this location other then moving the proxy to the correct network for nbd connections. With that move some how made the ipv6 issue appear. So it was just easy to disable ipv6 in the proxy. I guess if we ever switch to ipv6 (no plans too) then i guess i will have to look back into it. If any of your VMs are facing the public internet, completing your IPv6 Readiness compliance is vital. With regional internet registries completely exhausted of free-pool IPv4 space, modern endpoints and cloud architectures are increasingly deploying IPv6-only infrastructure. If you are referring to an internet access proxy, disabling IPv6 introduces significant architectural risk. If any upstream transit provider, carrier, or edge CDN in the path to your target FQDN transitions to an IPv6-only topology, your access path will break, causing a hard outage. If you are specifically utilizing a transit provider like XO Proxy, transitioning to dual-stack or IPv6-only transport is even more critical to ensure deterministic routing across the wider internet footprint. From an architecture and security standpoint, IPv6 introduces critical enterprise enhancements: • SLAAC Privacy Extensions: Enables temporary, rotating addresses to mitigate device fingerprinting and endpoint tracking. • Native IPSec Integration: While RFC 8200 technically shifted IPSec from a hard protocol requirement to an optional component, it remains a native architectural element of the IPv6 stack. Unlike IPv4—where IPSec must be bolted on as an awkward overlay—IPv6 accommodates encryption headers natively, simplifying the deployment of secure end-to-end transport encryption across enterprise and government domains. If you need to pitch this network-wide transition to leadership for project approval, I highly recommend framing it around business continuity and risk mitigation. Pointing out the looming vulnerability of upstream IPv6-only transit paths—combined with the compliance advantages of native architectural security—should give you the exact leverage needed to get this budgeted, planned, and implemented.
  • Our hyperconverged storage solution

    54 Topics
    824 Posts
    J
    @poddingue Turns out it is all secondary-to-secondary out of sync. So that makes it less intense, though if primary dies I wonder how it will resolve this, or if it will become split brained. Still unsure of how it happened, but the ones I manually cleaned up have not come back. Going to continue to manually clear them up. If it happens again I will have an alert setup to notify me, and I have all the xcp-ng logs and everything to be able to see what happened. If that happens I will post here with details and logs for the resource so we can see how it occurs. [image: image.jpeg]
  • 37 Topics
    136 Posts
    J
    @AtaxyaNetwork Merci pour tes recherches ! Oui "cd_label" serait cool comme ajout au plugin ce qui permet sur les distro type Fedora/Redhat de ne pas avoir de boot_command à gérer