Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    4k Posts
    pkgwP
    @stormi That is quite possible. I'll open a ticket for further investigation.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    Y
    Hello @codemercenary In theory Xen is NUMA aware (See https://wiki.xenproject.org/wiki/Xen_on_NUMA_Machines) so you would leave memory interleaving option of the BIOS off so that Xen does what it thinks is necessary. But these kinds of settings are very very workload sensitive and in fact it's usually a good idea to just test what works best for you. Regards, Yann
  • 3k Topics
    28k Posts
    G
    @john.c This is a good idea as well. If the previous suggestion of trying to do a DNS round robin approach doesn't work, this may be my best option. Thanks for taking the time to provide your suggestion!
  • Our hyperconverged storage solution

    45 Topics
    732 Posts
    DAYELAD
    Hello, I’m experiencing an issue on an XCP-ng cluster using XOSTOR. Environment: 3-node XCP-ng cluster XOSTOR distributed storage (2x2Tob nvme on each host) XOA for management Management network 1Gb/s Storage Network 10Gb/s MTU 1500 everywhere (no jumbo frames) So during VM migrations, creation, destroy XOA loses connection to my host pool, VMs keep running normally Hosts remain reachable (SSH / HTTPS / ping OK), Connection comes back after some time 30s to 1min. Observations: No significant CPU or RAM saturation No obvious disk latency issues (iostat looks normal) No errors reported on NICs xapi process remains active (no crash or freeze) The problem is intermittent and seems random. i've monitored nic with iftop and i see no bandwith bottleneck et and can see that XOSTOR is using 10gb network only. Has anyone experienced similar behavior with XOSTOR? And how to Fix it ? Thanks in advance for your help.
  • 34 Topics
    102 Posts
    B
    La remarque a été intégrée dans l'article: https://www.myprivatelab.tech/xcp_lab_v2_ha#perte-master Merci encore pour le retour.