Skip to content

fix(vm): reboot after disk resize when disk is not hotpluggable#2686

Merged
bpg-dev merged 1 commit intomainfrom
fix/2684-provider-does-not-reboot-vm-after-disk-resize
Mar 13, 2026
Merged

fix(vm): reboot after disk resize when disk is not hotpluggable#2686
bpg-dev merged 1 commit intomainfrom
fix/2684-provider-does-not-reboot-vm-after-disk-resize

Conversation

@bpg-dev
Copy link
Copy Markdown
Member

@bpg-dev bpg-dev commented Mar 12, 2026

What does this PR do?

Fixes an issue where resizing a disk on a running VM did not trigger a reboot when disk was excluded from the hotplug setting. After the hotplug fix in #2412, CPU/memory/network changes are hotplugged without reboot. If the only change is a disk size increase and disk is not hotpluggable, rebootRequired stays false, no reboot occurs, and cloud-init's growpart never runs — leaving the guest filesystem at the old size.

This PR makes two changes:

  1. Fix isHotpluggable() default — when hotplug is not explicitly configured, PVE defaults to network,disk,usb. Previously isHotpluggable() returned false for all features in this case.
  2. Add post-resize reboot — after disk resize on a running VM, if disk is not hotpluggable, reboot the VM so the guest OS can process the size change. Respects reboot_after_update = false by emitting a warning instead. In the combined case (config change + disk resize + non-hotpluggable), the VM reboots twice: once before resize (for config) and once after (for the guest to see the new size).

Contributor's Note

  • I have run make lint and fixed any issues.
  • I have updated documentation (FWK: schema descriptions + make docs; SDK: manual /docs/ edits).
  • I have added / updated acceptance tests (required for new resources and bug fixes — see ADR-006).
  • I have considered backward compatibility (no breaking schema changes without ! in PR title).
  • For new resources: I followed the reference examples.
  • I have run make example to verify the change works (mainly for SDK / provider config changes).

Proof of Work

TDD RED phase — test fails without fix (no reboot after disk resize):

$ ./testacc TestAccResourceVMDiskResizeNonHotpluggable
--- FAIL: TestAccResourceVMDiskResizeNonHotpluggable (29.06s)
    resource_vm_disks_test.go:2055: Step 2/2 error: Check failed: Check 2/2 error:
      VM was NOT rebooted after disk resize: uptime before=6, after=9 (expected reboot)
FAIL

TDD GREEN phase — test passes with fix (VM rebooted after resize, including double-reboot step):

$ ./testacc TestAccResourceVMDiskResizeNonHotpluggable -- -v
=== RUN   TestAccResourceVMDiskResizeNonHotpluggable
--- PASS: TestAccResourceVMDiskResizeNonHotpluggable (42.49s)
PASS
ok  	github.com/bpg/terraform-provider-proxmox/fwprovider/test	42.964s

Test verifies reboot via uptime check: captures VM uptime after step 1, asserts uptime reset (reboot occurred) after step 2 resize. Step 3 tests AIO change + resize (double reboot: pre-resize for config + post-resize for disk size).

Default hotplug test — no unnecessary reboot when disk is hotpluggable by default:

$ ./testacc TestAccResourceVMDiskResizeDefaultHotplug -- -v
=== RUN   TestAccResourceVMDiskResizeDefaultHotplug
--- PASS: TestAccResourceVMDiskResizeDefaultHotplug (32.10s)
PASS
ok  	github.com/bpg/terraform-provider-proxmox/fwprovider/test	37.177s

Test verifies NO reboot via uptime check: asserts uptime kept increasing (no reboot) after resize with PVE default hotplug.

Regression tests — no regressions:

$ ./testacc TestAccResourceVMDiskResizeWithOptionChange
ok  	github.com/bpg/terraform-provider-proxmox/fwprovider/test	36.574s

Community Note

  • Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for pull request followers and do not help prioritize the request

Closes #2684

Signed-off-by: Pavel Boldyrev <pavel@bpg.sh>
@bpg-dev bpg-dev requested a review from a team as a code owner March 12, 2026 11:03
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical issue where virtual machines would not reboot after a disk resize if the disk was not hotpluggable, preventing the guest OS from recognizing the increased storage. The changes ensure that the provider correctly identifies hotpluggable features based on Proxmox VE's defaults and triggers a necessary reboot when disk hotplug is disabled, allowing the guest OS to properly process the size change. It also refines the reboot_after_update behavior to provide warnings when reboots are suppressed.

Highlights

  • Disk Resize Reboot Logic: Implemented a mechanism to automatically reboot a running VM after a disk resize operation if the disk is not configured for hotplugging. This ensures the guest operating system can correctly recognize and utilize the new disk size, addressing a previous issue where cloud-init's growpart might not run.
  • Hotplug Default Correction: Corrected the isHotpluggable() function to accurately reflect Proxmox VE's default hotplug settings (network,disk,usb) when hotplug is not explicitly configured in the Terraform resource. Previously, it incorrectly returned false for all features in this scenario.
  • Reboot After Update Respect: Ensured that the reboot_after_update = false setting is respected. If a reboot is required after a disk resize but automatic reboots are disabled, the provider will now emit a warning instead of forcing a reboot.
  • Double Reboot Handling: Addressed scenarios involving both configuration changes and disk resizing, which may result in a 'double reboot' (one for config changes before resize, and another after resize for the guest OS to see the new disk size).
  • Comprehensive Acceptance Tests: Added new acceptance tests to validate the disk resize reboot behavior for non-hotpluggable disks, including the double-reboot scenario, and to confirm that no unnecessary reboots occur when disks are hotpluggable by default.
Changelog
  • docs/resources/virtual_environment_vm.md
    • Updated documentation for the hotplug attribute to clarify behavior during disk resizing.
    • Expanded documentation for the reboot_after_update attribute to include disk resize as a trigger for reboots.
  • fwprovider/test/resource_vm_disks_test.go
    • Added time import.
    • Introduced TestAccResourceVMDiskResizeNonHotpluggable to verify reboots for non-hotpluggable disk resizes, including double-reboot scenarios.
    • Added TestAccResourceVMDiskResizeDefaultHotplug to confirm no reboots occur when disk is hotpluggable by default.
  • proxmoxtf/resource/vm/vm.go
    • Defined dvHotplug constant for Proxmox VE's default hotplug value.
    • Modified isHotpluggable function to check against dvHotplug when the hotplug attribute is not explicitly set.
    • Implemented logic within vmUpdateDiskLocationAndSize to trigger a VM reboot after disk resize if the VM is running, not a template, and the disk is not hotpluggable, respecting reboot_after_update.
  • proxmoxtf/resource/vm/vm_test.go
    • Added new test cases to TestHotplugContains to validate the hotplugContains function with Proxmox VE's default hotplug values.
Activity
  • The author identified a bug where disk resizing on a running VM did not trigger a reboot when disk was excluded from hotplug, leading to cloud-init's growpart not running.
  • Initial tests (TDD RED phase) confirmed the failure, showing the VM was not rebooted after disk resize.
  • The author implemented fixes, including correcting isHotpluggable() default behavior and adding post-resize reboot logic.
  • Subsequent tests (TDD GREEN phase) passed, demonstrating that the VM now reboots correctly after resize, including double-reboot scenarios.
  • Additional tests were conducted to ensure no unnecessary reboots occur when disk is hotpluggable by default, and regression tests confirmed no new issues were introduced.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This PR provides a well-implemented fix for the issue where a non-hotpluggable disk resize didn't trigger a required reboot. The changes correctly adjust the default hotplug logic and add a post-resize reboot, ensuring the guest OS recognizes the new disk size. The accompanying acceptance tests are thorough, covering the fix, the double-reboot scenario, and preventing regressions. The documentation updates are also clear and helpful. I have one suggestion to improve maintainability by refactoring some duplicated code.

@bpg-dev bpg-dev merged commit 4ffb2f1 into main Mar 13, 2026
11 checks passed
@bpg-dev bpg-dev deleted the fix/2684-provider-does-not-reboot-vm-after-disk-resize branch March 13, 2026 09:33
@github-actions github-actions bot added status:in-progress The issue is being worked on and removed status:in-progress The issue is being worked on labels Mar 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Provider does not reboot VM after disk resize which leaves filesystem unchanged (not a bug probably, need some advice)

1 participant