Automatically reboot the VM when parameter changes

[arsensimonyanpicsart]

Is your feature request related to a problem? Please describe.
I’m always frustrated when I change the Proxmox VM hardware parameters, like RAM or CPU, because the Terraform provider automatically reboots the VM to apply the changes. This can be disruptive and is not always necessary immediately.

Describe the solution you'd like
I would like an option, such as automatic_reboot (a boolean), to be added to the Proxmox Terraform provider. When set to true, the VM would automatically reboot to apply the changes. When set to false, the provider would emit a warning indicating that the VM needs to be rebooted but would not automatically perform the reboot. This gives users more control over when reboots occur.

Describe alternatives you've considered
An alternative solution could be to manually track the changes and handle the reboots outside of the Terraform provider, but this approach is error-prone and less efficient.

Additional context
Adding this option would greatly improve the flexibility and usability of the Proxmox Terraform provider, allowing users to manage VM reboots according to their specific needs and schedules. This feature would prevent unnecessary disruptions in environments where immediate reboots are not feasible.

[waza-ari]

I'd love this, maybe even combined with a review on what changes actually do require a reboot. I've been transitioning to the new version, basically changing initialization.dns.server to initialization.dns.servers (with an array with the same DNS server as before being the only entry), which caused a reboot of the server, catching me completely off guard.

Having the option to emit the warning and reboot on your own pace (potentially in a maintenance window) would be a great addition.

[arsensimonyanpicsart]

Hello ! it is still very actual !

[dante11235]

This is just what I am looking for. I'm starting to use proxmox with terraform and this is possibly the most important feature. I spinup kubernetes clusters with terraform + rancher and this would be greatly appreciated. It would really suck to reboot all nodes at the same time. Now i have to have each server own .tf configuration so when i do changes i change it on one server at a time and it is counterintuitive for terraform.

[waza-ari]

Now i have to have each server own .tf configuration so when i do changes i change it on one server at a time and it is counterintuitive for terraform.

You can also always use a targeted plan and apply to target single servers, independently how they're declared. Not to say this feature is not important, but as an interim workaround that might serve you as well.

[bpg]

I see this ticket has gained a lot of traction, so I’ll address it in the next release :)

Currently, changes to any of these attributes will cause a VM reboot:

• acpi
• agent
• audio_device
• bios
• boot_order
• cpu
• disk
  • aio
• efi_disk
• hostpci
• initialization
• keyboard_layout
• kvm_arguments
• machine
• memory
• network_device
• numa
• operating_system
• scsi_hardware
• serial_device
• tablet_device
• template
• tpm_state
• usb
• vga
• watchdog

Note that most issues with VM auto-reboot on disk changes should be solved in v0.66.2 (#1580)

I haven't done any review yet, whether reboot is really necessary to apply those changes, and appreciate any help. Unfortunately, there is no clear documentation on what changes require reboot. So I'm thinking about just going manually over the list and try to change them via UI. If the new value is shown in yellow, then reboot is required:

[waza-ari]

Hi, first of all, thanks for taking the time! I'm not aware of any documentation either, so probably the test you suggested is pretty much the way to go.

This does raise a question though: even if a certain attribute requires a reboot to change, would be an option to make it configurable (potentially on the provider level, or even better, on resource level)? The following workflow might be desired:

Make all configuration changes through the provider, but opt not to restart the VM. Then, depending on your availability needs, restart them in a maintenance window or have the application owner reboot the machine on their own pace. If you're not concerned about that, you can configure the provider to auto restart (in fact, this should probably be the default, as everything else would break backwards compatibility).

Any thoughts?

[bpg]

Make all configuration changes through the provider, but opt not to restart the VM. Then, depending on your availability needs, restart them in a maintenance window or have the application owner reboot the machine on their own pace. If you're not concerned about that, you can configure the provider to auto restart (in fact, this should probably be the default, as everything else would break backwards compatibility).

That's exactly what I'm thinking 🙂. The provider maintains the current behavior by default, automatically restarting the VM. But users can opt-out by using a new attribute to receive a warning(s) instead, similar to what was described in the original proposal.