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
    ForzaF
    I just saw that Xen 4.21 was released. It has support for amd-cppc and amd-cppc-epp and resizable BAR. Looks to be good release They even have a quote from @olivierlambert too - here's hoping we get Xen 4.21 in next XCP-ng release https://www.linuxfoundation.org/press/xen-project-delivers-xen-4.21-a-modernized-hypervisor-with-broader-architecture-support-and-improved-performance

  • All Xen Orchestra related questions/reports

    3k Topics
    26k Posts
    cbaguzmanC
    Hi, it's great to be back! Until now, I've been performing backups on NFS media without the "Encrypt all new data sent to this remote" option and without the "Store backup as multiple data blocks instead of a whole VHD file." option. This allowed me to perform integrity checks on the backup files using a script that utilizes "vhd-cli check"and "xva-validate". Now I need to change the backup methods by enabling "Encrypt all new data sent to this remote" and "Store backup as multiple data blocks instead of a whole VHD file.". My question is whether there are any commands that allow me to verify the integrity of the backup files from the command line in this new scenario. I have VMs that are several GB in size, so using Auto Restore Check is not an option for me.

  • 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 ^^