[x] Is your issue/contribution related with enabling some setting/option exposed by libvirt that the plugin does not yet support, or requires changing/extending the provider terraform schema?
[x] Make sure you explain why this option is important to you, why it should be important to everyone. Describe your use-case with detail and provide examples where possible. See 1. hereunder in Issue description
[x] If it is a very special case, consider using the XSLT support in the provider to tweak the definition instead of opening an issue. See 2. hereunder in Issue description
[x] Maintainers do not have expertise in every libvirt setting, so please, describe the feature and how it is used. Link to the appropriate documentation. See hereunder in Issue description
Description of Issue/Question
Setup
Not tf specific
Steps to Reproduce Issue
Not a bug
Additional information:
Do you have SELinux or Apparmor/Firewall enabled? Some special configuration?
Have you tried to reproduce the issue without them enabled?
Not relevant here
Issue description
In its current state, it does not seem that the provider supports Secure Boot without some xslt modification.
Secure boot may be relevant these days in virtualization, and as UEFI boot-loader are already supported via OVMF by the provider, it may make sense to extend the provider to allow for secure boot support?
As we're tweaking the CPU, xslt may not be the best way to do the modification as the provider may not correctly detect the changes and try to re-apply a new VM, hence disrupting the existing one.
As OVMF is already supported, enabling secure boot is essentially a matter of:
Enable SMM CPU feature
Enable Secure boot flag
Regarding code-base actual changes it means at least:
Enabling SMM feature - already supported in upstream go-libvirt - in newDomainDef
Adding a secure_boot option in the libvirt domain schema in resourceLibvirtDomain. The .tf file could look like:
resource "libvirt_domain" "domain" {
count = 2
name = "ubuntu-cloud-${count.index}"
memory = "512"
vcpu = 1
machine = "pc-q35-6.2"
# This file is usually present as part of the ovmf firmware package in many
# Linux distributions.
firmware = "/usr/share/OVMF/OVMF_CODE.fd"
secure_boot = true
disk {
volume_id = element(libvirt_volume.volume.*.id, count.index)
}
graphics {
type = "spice"
listen_type = "address"
autoport = true
}
}
Adjusting setFirmware() in resourceLibvirtDomain, tweaking domainDef.OS.Loader with an additional Secure attribute depending on the aforementioned secure_boot flag in the .tf file.
One caveat is that "secure" Secure Boot with SMM and OVMF needs Q35 - with all the implication of using Q35 over i440FX.
On top of my head, missing IDE support would certainly impact cloud-init ISO workflows.
System Information
Linux distribution
Ubuntu 22.04
Terraform version
Provider and libvirt versions
Checklist
[x] Is your issue/contribution related with enabling some setting/option exposed by libvirt that the plugin does not yet support, or requires changing/extending the provider terraform schema?
See 1. hereunder in Issue description
See 2. hereunder in Issue description
See hereunder in Issue description
Description of Issue/Question
Setup
Not tf specific
Steps to Reproduce Issue
Not a bug
Additional information:
Do you have SELinux or Apparmor/Firewall enabled? Some special configuration? Have you tried to reproduce the issue without them enabled?
Not relevant here
Issue description
In its current state, it does not seem that the provider supports Secure Boot without some xslt modification.
Regarding code-base actual changes it means at least:
Adding a secure_boot option in the libvirt domain schema in resourceLibvirtDomain. The .tf file could look like:
setFirmware()
in resourceLibvirtDomain, tweakingdomainDef.OS.Loader
with an additionalSecure
attribute depending on the aforementioned secure_boot flag in the .tf file.One caveat is that "secure" Secure Boot with SMM and OVMF needs Q35 - with all the implication of using
Q35
overi440FX
. On top of my head, missing IDE support would certainly impact cloud-init ISO workflows.