Open sofixa opened 3 years ago
So, after some more digging, we've narrowed down the cause for this problem.
ovf_mapping
is used for the key of the storage_mapping struct ( spec here ). If it isn't set ( why would it be, the terraform docs mention it once and it says (optional), terraform sends an empty key, like so:
NetworkMappings: ([]vcenter.NetworkMapping) (len=2 cap=2) {
(vcenter.NetworkMapping) {
Key: (string) "",
Value: (string) (len=15) "dvportgroup-128"
},
which the vCenter doesn't appreciate, with the resulting vapi log:
com.vmware.vapi.bindings.convert.ConverterException: Could not convert field 'network_mappings' of structure 'com.vmware.vcenter.ovf.library_item.resource_pool_deployment_spec'
at com.vmware.vapi.internal.bindings.convert.impl.JavaClassStructConverter.fromValue(JavaClassStructConverter.java:89)
at com.vmware.vapi.internal.bindings.convert.impl.JavaClassStructConverter.fromValue(JavaClassStructConverter.java:33)
at com.vmware.vapi.internal.bindings.TypeConverterImpl$ValueToJavaVisitor.visit(TypeConverterImpl.java:281)
at com.vmware.vapi.bindings.type.StructType.accept(StructType.java:372)
at com.vmware.vapi.internal.bindings.TypeConverterImpl$ValueToJavaVisitor.visit(TypeConverterImpl.java:305)
at com.vmware.vapi.bindings.type.TypeReference.accept(TypeReference.java:20)
at com.vmware.vapi.internal.bindings.TypeConverterImpl.convertToJava(TypeConverterImpl.java:661)
at com.vmware.vapi.internal.bindings.StructValueExtractor.valueForField(StructValueExtractor.java:46)
at com.vmware.vcenter.ovf.LibraryItemApiInterface$DeployApiMethod.doInvoke(LibraryItemApiInterface.java:44)
at com.vmware.vapi.internal.bindings.ApiMethodSkeleton.invoke(ApiMethodSkeleton.java:175)
at com.vmware.vapi.provider.ApiMethodBasedApiInterface.invoke(ApiMethodBasedApiInterface.java:82)
at com.vmware.vapi.provider.local.LocalProvider.invokeMethodInt(LocalProvider.java:471)
at com.vmware.vapi.provider.local.LocalProvider.invoke(LocalProvider.java:290)
at com.vmware.vapi.admin.interposer.impl.Invoker.execute(Invoker.java:46)
at com.vmware.vapi.admin.interposer.impl.PreInterposerHandler.execute(PreInterposerHandler.java:57)
at com.vmware.vapi.admin.interposer.impl.VetoInterposerHandler.execute(VetoInterposerHandler.java:51)
at com.vmware.vapi.admin.impl.InterposerImpl.invoke(InterposerImpl.java:277)
at com.vmware.vdcs.activation.ActivationFilter.invoke(ActivationFilter.java:123)
at com.vmware.vapi.core.DecoratorApiProvider.invoke(DecoratorApiProvider.java:37)
at com.vmware.vsphere.common.impl.SecurityContextInterceptorProvider.invoke(SecurityContextInterceptorProvider.java:72)
at com.vmware.vapi.cis.authz.impl.AuthorizationFilter.invoke(AuthorizationFilter.java:219)
at com.vmware.vapi.provider.introspection.ErrorAugmentingFilter.invoke(ErrorAugmentingFilter.java:74)
at com.vmware.vapi.security.AuthenticationFilter$1.setResult(AuthenticationFilter.java:180)
at com.vmware.vapi.security.AuthenticationFilter$1.setResult(AuthenticationFilter.java:166)
at com.vmware.vsphere.common.sessions.impl.SessionAuthnHandlerImpl.authenticate(SessionAuthnHandlerImpl.java:42)
at com.vmware.vapi.security.AuthenticationFilter.invoke(AuthenticationFilter.java:165)
at com.vmware.vapi.core.DecoratorApiProvider.invoke(DecoratorApiProvider.java:37)
at com.vmware.vsphere.vcde.diagnostics.interceptor.ApiDiagnosticsInterceptorProvider.invoke(ApiDiagnosticsInterceptorProvider.java:50)
at com.vmware.vapi.protocol.server.msg.json.JsonServerConnection.processApiRequest(JsonServerConnection.java:275)
at com.vmware.vapi.protocol.server.msg.json.JsonServerConnection.requestReceived(JsonServerConnection.java:200)
at com.vmware.vapi.protocol.server.rpc.http.impl.HttpStreamingServlet.doPostImpl(HttpStreamingServlet.java:124)
at com.vmware.vapi.protocol.server.rpc.http.impl.HttpStreamingServlet.doPost(HttpStreamingServlet.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:615)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1627)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.vmware.vapi.bindings.convert.ConverterException: Element already present in the map.
at com.vmware.vapi.internal.bindings.convert.impl.JavaUtilMapMapConverter.fromValue(JavaUtilMapMapConverter.java:62)
at com.vmware.vapi.internal.bindings.convert.impl.JavaUtilMapMapConverter.fromValue(JavaUtilMapMapConverter.java:30)
at com.vmware.vapi.internal.bindings.TypeConverterImpl$ValueToJavaVisitor.visit(TypeConverterImpl.java:264)
at com.vmware.vapi.bindings.type.MapType.accept(MapType.java:42)
at com.vmware.vapi.internal.bindings.TypeConverterImpl.convertToJava(TypeConverterImpl.java:661)
at com.vmware.vapi.internal.bindings.convert.impl.NullableReferenceOptionalConverter.fromValue(NullableReferenceOptionalConverter.java:33)
at com.vmware.vapi.internal.bindings.convert.impl.NullableReferenceOptionalConverter.fromValue(NullableReferenceOptionalConverter.java:23)
at com.vmware.vapi.internal.bindings.TypeConverterImpl$ValueToJavaVisitor.visit(TypeConverterImpl.java:239)
at com.vmware.vapi.bindings.type.OptionalType.accept(OptionalType.java:24)
at com.vmware.vapi.internal.bindings.TypeConverterImpl.convertToJava(TypeConverterImpl.java:661)
at com.vmware.vapi.internal.bindings.convert.impl.JavaClassStructConverter.fromValue(JavaClassStructConverter.java:86)
... 51 more
Once we know that, it's easy, just set ovf_mapping on the network_interface block:
network_interface {
network_id = data.vsphere_network.network_bkp.id
adapter_type = "vmxnet3"
ovf_mapping = "nic0"
}
network_interface {
network_id = data.vsphere_network.network_adm.id
adapter_type = "vmxnet3"
ovf_mapping = "nic1"
}
IMHO, at the very least, that needs to be documented much better. I'd even go as far as setting a default value if ovf_mapping is empty.
It's even worse with storage:
ovf_mapping is used for the key, but there is no such thing :
How can we proceed? I'm open to writing a PR with the documentation change and sane defaults for network ovf_mapping, but i have no idea about storage mapping.
I'm running into this same issue. I'm trying to deploy an OVF from a content library and when I have 1 NIC specified it deploys normally. When I add additional NICs it fails with the same 500 error response from vSphere.
Did you specify ovf_mapping
for each NIC?
By using ovf_mapping = var.ovf_map[network_interface.key]
in the dynamic network_interface mentioned above we are not running the same problem anymore.
We use it with the variable below:
variable "ovf_map" {
type = list(string)
default = ["eth0", "eth1", "eth2", "eth3"]
}
It should work even if you're not using a dynamic for your NIC by just specifying eth0, eth1 anyway.
Per the VMware vSphere product documentation, which compares the use of VM Templates vs OVF Templates in Content Library:
"During the deployment of an OVF template, only guest OS customization is supported. Hardware customization is not supported."
Reference: The VM Template as a Content Library Item
Hardware guest customization for OVF templates would need to be supported in vSphere to enable this capability.
Regards, Ryan
Similar to #1441
cc @appilon and @iBrandyJackson for review and closure.
Closing as per @tenthirtyam recommendation
@appilon @tenthirtyam I don't see the link between hardware customisation and the fact that it's pretty non-obvious how to deploy an OVF template because terraform has optional parameters that are in fact required by VMware ( and rather useless i might say). Having that clearer in the docs and/or having defaults on the terraform side would make for an easier UX.
So i checked the linked issue and it's an unrelated problem :) Manually mapping nics and disks fixes the 500 from this one. @appilon could you please reopen this one?
@appilon, we can retest and pick it up in a doc update in the least. @sofixa, feel free to suggest a resolution in a pull request.
Ryan
I'll re-open and have it close once we at least provide a documentation update
Terraform Version
0.14.6
vSphere Provider Version
1.24.3
Affected Resource(s)
vsphere_virtual_machine
Terraform Configuration Files
Debug Output
https://gist.github.com/sofixa/4cd7740a8628d5a43ec4db5fb75a5594 Note: this is with a custom build of the provider with extra logs and most notably the deployment spec of the template.
Expected Behavior
The content library OVF template should have been successfully deployed since there's nothing weird or special about it. The exact same template, with almost the same options gets deployed just fine with PowerCLI or govc, so it's something in terraform ( the differences are in the number of network interfaces and disks since we can't tell PowerCLI or govc to make multiple of them). The gist contains the specs generated by govc and terraform.
Actual Behavior
As per usual, a completely useless error from VMware. After going through the logs, there doesn't seem to be anything suspicious.
Steps to Reproduce
Try deploying a content library OVF template??? Not really sure what's causing the issue
How can we proceed about debugging this further? I found this issue in govmomi which seemed like a potential cause, but it was fixed in ~0.23, and when i rebuilt the provider with govmomi v0.24.0 the problem is still there, and govc 0.21 doesn't have any issues, so it's not that.
Community Note