[2.5] KVM pod deployment does not support ppc64
Bug #1797484 reported by
Mike Pontillo
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
High
|
Mike Pontillo |
Bug Description
KVM pod deployment needs to be tested on a PPC64 host.
It is our current understanding that in order for libvirt to be used with KVM on PPC64, the following command needs to be run (as root) on the hypervisor before libvirt is usable:
ppc64_cpu --smt=off
More details can be found here:
https:/
See also: bug #1794560 (for the AMD64 architecture)
Related branches
~mpontillo/maas:ppc64-disable-smt-for-pod-deploy--bug-1797484
Merged
into
maas:master
- Andres Rodriguez (community): Approve
- MAAS Lander: Approve
- Lee Trager (community): Needs Information
-
Diff: 123 lines (+50/-10)4 files modifiedsrc/maasserver/node_action.py (+3/-1)
src/maasserver/tests/test_node_action.py (+6/-2)
src/metadataserver/tests/test_vendor_data.py (+18/-0)
src/metadataserver/vendor_data.py (+23/-7)
description: | updated |
summary: |
- [2.5] KVM pod deployment needs validation on ppc64 + [2.5] KVM pod deployment does not support ppc64 |
Changed in maas: | |
assignee: | nobody → Mike Pontillo (mpontillo) |
status: | Triaged → In Progress |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in maas: | |
milestone: | 2.5.0rc1 → 2.5.0beta4 |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I'm not sure how to work around this cleanly when deploying a KVM pod.
We can add an /etc/rc.local similar to the following:
#!/bin/sh
ppc64_cpu --smt=off
exit 0
... which I prototyped, but I'm not sure about. It really seems like a hack. For example, is there a chance that libvirtd could start up before this gets executed? If so, what would be the effects of that race condition? (Is there another solution, such as a kernel parameter or sysctl, that would be better?)
Given that SMT refers to multithreaded CPU cores, would passing `smt=1` as a kernel parameter be more efficient at accomplishing this? (According to what I found in kernel- parameters. txt in the Linux documentation, smt=1 and nosmt are equivalent, but nosmt=force might be even safer.)
We should test this on actual hardware to confirm any proposed solution before moving forward with this.