Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    TeddyAstieT
    @leroyj We already know that our k10temp module doesn't have support beyond Zen 2, and needs to be updated. That's not incredibly complex, but still needs to be done. I was wondering if the amd cpu temp be probed the way you did for the intel cpu. No, AMD temperature infos are not exposed through MSR but through PCIe/MMIO (through various subsystems, like "SMU" and other ones). Like what does https://github.com/torvalds/linux/blob/master/drivers/hwmon/k10temp.c or https://github.com/ocerman/zenpower. (regarding the AI draft, there is no documented MSR 0xc0010292 in neither APM nor public Zen3 PPM) That doesn't require any specific Xen support aside the right Linux drivers in Dom0.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    J
    @poddingue Thanks for taking a look. Yes it is this part that tells me that it should start the VM automatically once the import has completed. "After the transfer, the VM on XCP-ng side is started:" Followed by, "This process is fully automated, without any human intervention after it starts on step 1." [image: image.jpeg] https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/ But my findings/experience is that the VM does not start once the import/transfer has completed. So either the docs are wrong. Or the function is not behaving as intended. I'm acctually fine either way. As long as I know what to expect. However, I would like to have it auto-start the VMs after transfer completion. Which would make the procedure "Fully automated".

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    poddingueP
    @carloum70 the same address on both xenbr4 and xapi1 looks like the best lead so far. I haven't tested it, but two interfaces answering for 172.28.4.11, with two routes to the same subnet, could send heartbeat traffic out the wrong NIC now and then, and that would fit the drops in your xha.log. bleader untangled something close to it in https://xcp-ng.org/forum/topic/12472 (two bridges on one subnet, replies leaving by the wrong one). As for eth4: without --device, xe-reset-networking takes the NIC recorded at install time in /etc/firstboot.d/data/management.conf, so I think it's just remembering the installer's choice. I'd hold off on @tjkreidl's worst-case reset for now, because the docs say it wipes all PIF, bond and VLAN config, force-stops VMs, and isn't supported while HA is on (Emergency Network Reset). xe pif-list host-name-label=dacshyp002 params=device,IP-configuration-mode,IP,management only lists, and it would show whether XAPI itself thinks eth4 has that IP; if it does, @Team-XAPI-Network will know the clean way to drop it.

  • Our hyperconverged storage solution

    54 Topics
    820 Posts
    K
    @ronan-a Unfortunately, the same issue persists even with a reduced MTU. We are experimenting with alternative solutions to replace a "commercial solution" on HCI infrastructure, and I am afraid that issues like this are unacceptable. I used Xen a long time ago and thought XCP-ng would be an excellent solution—and it very likely is, when used with a traditional storage system.

  • Non-English speakers

    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