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
    poddingueP
    @jr-m4 I think this may be two doc pages disagreeing rather than a bug, though I could be wrong. The XCP-ng docs say the VM is started after the transfer (How it works), but the XO V2V guide says to start the VM yourself once the migration is complete (step-by-step procedure). I had a look at the import code on master, and at the end it only removes the start lock it puts on the VM during the transfer. I couldn't find anything that boots it. Was it the XCP-ng page you had in mind? If auto-start is supposed to happen, @Team-XO-Backend will know, and if not, that page needs fixing.

  • 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