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". Update: Am I assuming correctly that "the XO V2V guide says to start the VM yourself once the migration is complete " you're reffering to, is part of the "test migration"-procedure? Not the acctual production mgiration? Because: "Final migration Run the production migration When you're ready for the final migration: Shut down the source VM completely. Start the V2V migration in Xen Orchestra with the Stop source option enabled. This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies." In my mind doesn't state that the VM should be started manually post-transfer. Great thanks in advance for discussing! Cheers!
  • 3k Topics
    29k Posts
    C
    @john.c now I remember, during the installation we used the eth4 as the management interface. [16:54 dacshyp002 ~]# cat /etc/firstboot.d/data/management.conf LABEL='eth4' MODE='static' IP='172.28.4.11' NETMASK='255.255.252.0' GATEWAY='172.28.4.1' MODEV6='none' DNS='8.8.8.8' Afterwords we created a bond bond0 with eth2/eth3 and used this as the management interface. The xe pif-list command shows the following: device ( RO) : bond0 management ( RO): true IP-configuration-mode ( RO): Static IP ( RO): 172.28.4.11 device ( RO) : eth4 management ( RO): false IP-configuration-mode ( RO): Static IP ( RO): 172.28.4.11 Is it that easy to remove the IP address from the eth4 interface? Because it make no sense to have duplicate ip-addresses. I think we've had duplicate IP addresses all along, but we only noticed the issue after enabling HA. By the way what is the correct way to change the management interface? We used the xsconsole.
  • Our hyperconverged storage solution

    54 Topics
    823 Posts
    K
    @ronan-a For testing purposes, I did the following: I created a VM on the local SR of a host, installed Linux on it, and configured an ISCSI target. I then added that ISCSI target as an ISCSI SR within xcp-ng pool, and created a small VM on that repository, using XO. While the machine was running, I performed a migration without losing a single ping.I assume this confirms my previous assertion regarding the use of a standard storage system.
  • 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