Categories

  • All news regarding Xen and XCP-ng ecosystem

    139 Topics
    4k Posts
    D
    @dom0 Yes, the Vates tools are our recommended guest tools for XCP-ng going forward.

  • Everything related to the virtualization platform

    1k Topics
    14k Posts
    D
    Hi everyone, Did anyone else notice that built in SR "XCP-ng VM Tools" cannot be seen by XCP-ng Center 25.0.4 ? [image: 1764231081221-screenshot-from-2025-11-27-09-03-30.png] Happens on 8.3 and 8.2, did not test below that... XO sees it and can mount it SR is visible, PBD was not disconnected Only way for me to get it to work in combo 8.3 + 25.0.4 was to destroy SR and add it from the scratch...

  • All Xen Orchestra related questions/reports

    3k Topics
    26k Posts
    P
    @pdonias said in ️ XO 6: dedicated thread for all your feedback!: @jr-m4 Thanks for the feedback! I tried to reproduce that but I don't seem to get the same behaviour. Let me make sure I understood: You select a template VDI names get prefilled automatically You select another template VDI names don't change automatically (but on my side it looks like they do change) Could you confirm that? This is my other account. Acctually. The VDI name does change. But it changes to the name of the previous selected template. This is the steps I do, and it is reproducible I choose to create new vm I choose the first template. (Almalinux VDI is named: disk_0_rggi Without leaving the page. Choosing another template instead. (CentOS 7) The VDI is now named: AlmaLinux 8_0_3cgh This behaviour repeats each time a new template is chosen.

  • 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

    31 Topics
    87 Posts
    olivierlambertO
    Let me ping @gregoire and maybe @psafont