This message was deleted.
# harvestera
adamant-kite-43734
04/01/2026, 8:47 PMThis message was deleted.
g
great-bear-19718
04/01/2026, 10:16 PMby default kubevirt on boot checks the os arch based on where virt-controller is scheduled, and based on the ARCH it applies defaults and restricts bus types etc in vm spec
great-bear-19718
04/01/2026, 10:17 PMin mixed arch cluster based on where the virt-api and controller get scheduled you will get different defaults / mutation / validation logic applied which will lead to issues with running VM's
great-bear-19718
04/01/2026, 10:17 PMfrom Harvester perspective the upgrades will not work since the upgrade controller downloads iso based on again where the leader upgrade controller pod is running
great-bear-19718
04/01/2026, 10:18 PMthe iso is used to apply OS updates eventually and it needs work to support mixed arch clusters
c
chilly-gigabyte-21629
04/02/2026, 1:09 AMgotcha. you confirmed my suspicions about their being hardcoded logic that would work against multi arch clusters. Is mixed arch something we want to support? I have 2 nodes I am testing this out on and debating making them both arm or keeping one x86 and contributing back some mixed arch support. I totally understand there are upstream limitation buts there's no reason why harvester itself can't support it, even if longhorn probably never will (without a 3rd party drive abstraction) and kubevirt multi arch is experimental.
3 Views