Fix 1079 & 1139

[kvandenhoute]

Detach volumegroup that is attached on vm, before destroying the vm. Prismc does not allow to delete vm with attached volumegroup

fixes #1079 & #1139

[kvandenhoute]

it seems like linting is not ok on main branch

[kvandenhoute]

@GullapalliAkhil @Haroon-Dweikat-Ntx Please let me know if any changes are required

[Haroon-Dweikat-Ntx]

Hi @kvandenhoute, thank you for taking the time to work on this and submit a PR to address these issues!

While we understand the underlying problem with the VM deletion failing due to attached Volume Groups, we won't be able to merge this specific approach.

Adding the automatic disassociation logic to the VM deletion path goes against standard Terraform guidelines. Relationships and attachments should be managed by their specific attachment resources to maintain proper state and lifecycle management, rather than building that logic into the core VM resource itself.

To manage Volume Group attachments correctly, users should use the dedicated nutanix_volume_group_vm_v2 resource instead of configuring it directly within the VM resource. Using nutanix_volume_group_vm_v2 ensures that Terraform can properly handle the attach and detach operations independently in the dependency graph during apply and destroy operations.

Because of this, I'll be closing this PR, but we really appreciate your contribution and effort here!

[kvandenhoute]

Hi @Haroon-Dweikat-Ntx,

I feel you are contradicting yourself? You suggest us to use the adfs_volume_group_reference directly on the vm resource here: #1139 (comment)

In this comment you literally say to not split the attach from the vm:

"When the VM is managed by Terraform, attach the volume group inside the VM's disks block using backing_info.adfs_volume_group_reference, and do not use nutanix_volume_group_vm_v2 for that attachment. This keeps a single source of truth and eliminates the drift."

This PR fixes that you can actually do that, because this feature is currently bugged, confirmed on the other PR too: #1079 (comment)

Our original solution is to use the "nutanix_volume_group_vm_v2", which is exactly why we opened the PR: it does not work.
Because you then commented that you don't want us to use it and instead do it directly on the vm, I put work into fixing this.

Now you say you can not actually use this feature (then why is it available even?), and we should go back to our original solution, which does not work.

Please, with terraform provider 2.4.2 try yourself to create:
a volumegroup with atleast 1 disk
a vm that uses that volumegroup (so attach it) and cloud init

Now try:
a. changing something on the cloud-init triggering a recreate of the VM
b. destroying the vm
c. changing something non-replace on the vm
d. changing nothing on the vm

Neither of the two solutions work for all A,B,C,D.

Using the adfs_volume_group_reference on nutanix_vm_v2 won't allow A/B, it does work for C/D
Using the nutanix_volume_group_vm_v2 allows A/B but C/D will remove the attachment

Please reinvestigate these issues, as currently the provider is not workable with volumegroups.

I don't agree that this is anti-terraform, but if you'd like a detach flag could be added;
nutanix_vm_v2 : force_detach_disks_on_recreate or w/e

Please do not close this.

[Haroon-Dweikat-Ntx]

Hi @kvandenhoute,

First, I want to sincerely apologize for the mixed messaging here. You are absolutely right to call out the contradiction, and I completely understand how frustrating it is to be sent back and forth, especially after you put in the time and effort to build a fix for us.

You have summarized the current broken state perfectly:

• Inline (adfs_volume_group_reference): Fails on A/B (Destroy/Recreate) because the API rejects VM deletion with attached VGs.
• Standalone (nutanix_volume_group_vm_v2): Fails on C/D (In-place updates/No-op) because the VM resource incorrectly sees the external attachment as drift and removes it.

When looking at this from a Terraform architecture perspective, the standalone resource (nutanix_volume_group_vm_v2) is the correct design pattern. My earlier advice on #1139 (to use inline) was a workaround attempt that ultimately led you down a path blocked by the API deletion constraints, which this PR valiantly tried to patch.

The good news is that we are actively working on a fix for the underlying drift issue, targeted for our next release (2.5.0). With this fix, the VM resource will no longer show a diff on apply or plan when a Volume Group is attached via the standalone resource, allowing scenarios A, B, C, and D to all work correctly.

Thank you again for holding us accountable and for your deep dive into these use cases. We really appreciate your patience while we get this properly resolved.

[kvandenhoute]

@Haroon-Dweikat-Ntx Ok that is great to hear, I'm looking forward to it being resolved.

I do fail to understand why the inline adfs_volume_group_reference then exists, if its purpose is not to use it. Maybe it should be removed, or documented that this feature is not advised to be used.