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
    AtaxyaNetworkA
    If I was in your place, I would do: Disconnect all USB used as SR Reinstall XCP-ng if you have only a few VMs, my option would be just to redeploy XOA, REATTACH the SR (not create, REATTACH, be careful, a create will wipe your disk) Recreate VMs, attach the VDI, boot from here if you have to many VM, directly after deploying XOA restore your metadata backup, it should be repluging the SR and create PDB at least (but it's been a while since I didn't use the metadata) In any case, backup everything, especially the VDI (.vhd). If you have the VDI, you can work around with the rest

  • All Xen Orchestra related questions/reports

    3k Topics
    26k Posts
    A
    @bvitnik This is creating new vm from Hub template. If i try the blow command VM hangs on boot. Think previously it would eventually boot but have not networking as stated previously. #cloud-config # network: version: 2 ethernets: enX0: dhcp4: true dhcp6: false set-name: "enX0" This is copy pasted from the link you provided about additional infomation to add to documentation. does not show network: commented out. When i use this with ips corrected to my network the vm boots fast but again still no networking. Even if i comment out network. Still no networking. I have to leave blank during vm creation. Can you past your working network config? #cloud-config network: version: 2 ethernets: eth0: dhcp4: false addresses: - 10.0.2.6/27 gateway4: 10.0.2.1 nameservers: addresses: - 10.0.2.1 - 1.1.1.1

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