-
Notifications
You must be signed in to change notification settings - Fork 58
Set firmware attribute in libvirt domain for aarch64 #214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -460,35 +460,43 @@ type Config struct { | |
| URI string | ||
| } | ||
|
|
||
| func domainDefInit(domainDef *libvirtxml.Domain, name string, memory, vcpu int) error { | ||
| if name != "" { | ||
| domainDef.Name = name | ||
| func setFirmware(input *CreateDomainInput, domainDef *libvirtxml.Domain, arch string) { | ||
| // for aarch64 speciffying this will automatically select the firmware and NVRAM file | ||
| // reference: https://libvirt.org/formatdomain.html#bios-bootloader | ||
| if arch == "aarch64" { | ||
| domainDef.OS.Firmware = "efi" | ||
| } | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am ok with hardcoding this for aarch64, but do we want to expose this through the machine provider api so it can be set through the installer and this code can be arch agnostic?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok..on second thought .. probably not...this is a basic property of aarch64...better to leave it as is and keep things simple
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It must not be so basic, otherwise it would be the libvirt default ;) I agree with leaving this as is for now, as I don't think cluster-api-provider-libvirt should support arbitrary VM configurations. This is one case where it should be able to pick up the correct value needed by openshift. For x86_64, the efi switch would happen when we start using the q35 machine type. |
||
| } | ||
|
|
||
| func domainDefInit(domainDef *libvirtxml.Domain, input *CreateDomainInput, arch string) error { | ||
| if input.DomainName != "" { | ||
| domainDef.Name = input.DomainName | ||
| } else { | ||
| return fmt.Errorf("machine does not have an name set") | ||
| } | ||
|
|
||
| if memory != 0 { | ||
| if input.DomainMemory != 0 { | ||
| domainDef.Memory = &libvirtxml.DomainMemory{ | ||
| Value: uint(memory), | ||
| Value: uint(input.DomainMemory), | ||
| Unit: "MiB", | ||
| } | ||
| } else { | ||
| return fmt.Errorf("machine does not have an DomainMemory set") | ||
| } | ||
|
|
||
| if vcpu != 0 { | ||
| if input.DomainVcpu != 0 { | ||
| domainDef.VCPU = &libvirtxml.DomainVCPU{ | ||
| Value: vcpu, | ||
| Value: input.DomainVcpu, | ||
| } | ||
| } else { | ||
| return fmt.Errorf("machine does not have an DomainVcpu set") | ||
| } | ||
|
|
||
| domainDef.CPU.Mode = "host-passthrough" | ||
| setFirmware(input, domainDef, arch) | ||
|
|
||
| //setConsoles(d, &domainDef) | ||
| //setCmdlineArgs(d, &domainDef) | ||
| //setFirmware(d, &domainDef) | ||
| //setBootDevices(d, &domainDef) | ||
|
|
||
| return nil | ||
|
|
||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's required to bump
libvirt-go, onlylibvirt-go-xmlshould be needed? If you bump thelibvirt-godependency, this can cause unexpected failures to run the installer (if you build on a system where libvirt 5.10 is installed and you then try to run it on a system with libvirt 4.6 installed). I'd prefer to keep the libvirt-go dependency unchanged if possible.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i changed libvirt-go and libvirt-go-xml to match that of the openshift installer. I thought it would be good to keep both in sync? in any case the installer uses the same versions so should be fine ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the installer upgraded to a newer version indirectly (it updated another module which needed a newer version). This caused issues fwiw openshift/installer#4339
Since we already bit the bullet with the installer, we can try changing it here as well :)