Add support for RDM disk mappings

[ghost]

This issue was originally opened by @showry as hashicorp/terraform#17283. It was migrated here as a result of the provider split. The original body of the issue is below.

---

As per the current terraform vsphere documentation,Terraform doesn't support RDM disk mappings. Is there any future scope that this feature gonna be supported?

[vancluever]

Hey @showry, sorry for the delay in replying on addressing this topic.

At this point, I don't think the vSphere provider is going too end up supporting RDM disks anytime soon. There are no plans to support these kinds of disks, and since their makeup under the hood is so much different from standard disks, we would need to take that into consideration when authoring support - they would probably need to be their own virtual device class (such as raw_disk), but share configuration data with standard disk sub-resources such as unit_number. We would also need to consider how we would track them, as we are now using the UUID of a disk's backing as the primary identifier for a disk device once it has been deployed.

Nothing is set in stone, of course - necessity may end up driving us to support this anyway, or we might get a pull request allowing for the support. But I don't want to leave this issue open saying "soon" disingenuously. Longer term you might want to check back to see if this has changed.

Thanks!

[surajsub]

For some of our sap installations this would be a key feature - How do i up this requirement ?

[vancluever]

@surajsub and @showry I think I may have closed this pre-maturely. I want to make sure this is tracked, even if it's a longer-term goal, so I'm re-opening the issue.

What I mentioned about our plans hasn't changed, so barring any the aforementioned factors, this won't be available for a while yet. But now at least it's available for us to track and update when work is ready.

@surajsub the 👍 implied in your message is enough to vote on this, otherwise the best way you could help speed up development of the feature is to see if anyone wanted to work on a PR 🙂

Thanks!

[pbusquemdf]

I too would like to have this feature added. We are using 3PAR remote copy to have replication of single instance application, and we can't provision those machine.

I do not mind Terraform not supporting RDM disk implicitly , if we can have an option to mark a disk to be ignored.

Right now, if we put the disk into the lifecycle-> ignore_changes we would still get the "unsupported type" error.

A workaround would be to parse the config, and if the device is an unsupported type AND marked as to be ignored, well, ignore it. If new drives are added afterward, handle those as you normally would.

That way, we can still use RDM until it is fully supported.

[scheying]

Same here. Right now we have to delete machines that have an RDM attached from the TF state. If Terraform would just ignore RDMs that would already help a lot.

[sergioagm]

We also are interested in this. We use RDM attached disks from a SAN to implement Windows Clusters. Either supporting them fully or as @pbusquemdf said, ignoring the RDM disk but still being able to manage the vm with Terraform would work for us.

[gvcgael]

Does anyone have any workaround ?

[sumitAgrawal007]

I have a PR out with this feature, people who are interested can try out the binary I have linked with the PR.
#1366

[gvcgael]

Any news on this merge request ?

[tkriviradev]

Much needed...

[dijarvrella]

Any news on this request?

[etosan]

I am part of the the team, where we (almost) successfully helped to implement automation stack for a client, with resource management based on terraform. The client is using vmware heavily.

After the relatively easy task of converting simpler systems to template based machines, I am hitting the roadblock with RDM volumes. We knew from documentation, that the provider lacked support for direct RDM management, but documentation was not exactly clear about RDM mapped files (from now on referred to as "RDM MF", if unclear see below).

These volume types are not that uncommon, especially in more complex specialty setups, like virtualized clusters, which is a case with this client as well.

There are several ways to present RDM volume to virtual machine in vmware vsphere:

• directly map LUN into the machine's SCSI address space using WWN
• use special so called RDM "mapping file" (which is our case) more here: RDM MF docs

With RDM MF the mapping for the FC LUN is stored in special .vmdk, that is know as "mapping file", instead of volume being mapped directly into the VM. For all intents and purposes, this file looks like regular VMDK, and it can be storage migrated etc, but it, in fact, points to the raw LUN instead. You can think of it like symlink or windows .lnk file. This way you get benefits of both: easy vmdk management and also of RDM advantages.

Because vsphere's provider supports "attach" for disk sub-resources, some people on our team hoped terraform would be able to attach these VMDK files as usual ... which turns out not to be the case.

If attach operation attempt is performed trough terraform this operation fails with nondescript error, which seems to be coming from deepr layers probably govmomi or even vphere itself (I can provide error if needed).

However RDM MF VMDK can still be attached manually through vsphere WEBUI just fine. This would be okay with me, as there are not that many machines with these requirements (around couple of dozens), and that can be configured manually (I am also investigating govc solution),

Unfortunately once terrafrom plan is run after such manual attachment, it dies complaining that it doesn't know what to to the RMD MF VMDK sub-resources, because they are of unknown type. This completely breaks the whole IaC stack. I will provide this error as well.

Because this is API error, no lifecycle spelunking can fix it, as terraform simply cannot be told to ignore/skip over these specific drives during resource discovery/scan phase.

Unfortunately, for us, all the people involved with the project came to like terraform quite a lot, so we are very distraught, by the fact that it cannot be used this way.

---

Thinking about it philosophically, classic resource management in terraform's understanding does not really make sense with regard to RDMs, RDMs are often provided and managed by deeper storage layers (storage arrays, SAN appliances and such), thus expecting terraform to mange them is overkill.

It would be much more efficient for everybody, both terrafrom and vcenter and us users, just to be able attach and detach RDM MFs by terraform and let them be managed form somewhere else, where it makes sense.

For us it would be sufficient for terraform to skip over the unknown RDM backed VMDK disk types, and treat them like "opaque" sub resource objects.

---

TLDR: Can we make terraform skip over RDM MF VMDK disks at provider level somehow? Ie. we just need to be able to attach and detach them to virtual machine resource, but never otherwise touch them, and never ever delete them. Storage experts can then manage the LUN device backing the virtual disks directly, using their own automation solutions, outside of vsphere and terraform's scope.

This should be much easier to implement than "full" RDM scope.

[etosan]

I also tried testing with code from #1366 but it seems that that implementation is designed to handle only directly mapped-in RDMs, and is completely unaware of RDM MFs. Also it does not seem to work with current main.

[etosan]

Just pinging @appilon, @redeux and @tenthirtyam, as they seem to be able to chime in on the possibility of my request, which is much simpler than "full" implementation of RDM, whatever that means.

[etosan]

Error reported by terraform when trying to run plan after attaching the RDM MF manually before plan run:

Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: disk.1: disk backing at scsi:1:0 is of an unsupported type (type *types.VirtualDiskRawDiskMappingVer1BackingInfo)
│ 
│   with vsphere_virtual_machine.gis-cluster-db-a01,
│   on vm-gis-cluster-db-a01.tf line 1, in resource "vsphere_virtual_machine" "gis-cluster-db-a01":
│    1: resource "vsphere_virtual_machine" "gis-cluster-db-a01" {
│ 

I believe that for all mapped RDM usecaces, just "ignoring" (as in no size extension, no delete on detach etc) the VirtualDiskRawDiskMappingVer1BackingInfo type would be sufficient. Disk subresource of this subtype would only need to support path= property (which is path to vmdk) and datastore_id= to "dereference" the mapping, attach= would be required to be always true, and label= and unit_number= are required to just "inject" the device into proper spot in vsphere_virtual_machine resource.

Maybe I am seeing it too simply, so please correct me if I am wrong.

[etosan]

I found out govc is hitting the same Incompatible device backing specified for device '0'. error, as terraform reports when trying to attach the RDM MF (this is the first error we hit I mentioned here). This points to RDM MF attachment handling being broken there on govmomi layer. So this need to be fixed first.

Even when that issue gets fixed, and both terraform and govc will then be able to attach the disk device, I expect terraform to probably fail later on unsupported type (type *types.VirtualDiskRawDiskMappingVer1BackingInfo). This would require to fix respective type handling in the provider maintained here.