Hi All,
I am getting an error Failure to construct resource name for : 'Cloud_vSphere_Network_1 while testing basic blueprint deployment test. PFA screenshot.
formatVersion: 1
inputs:
platform:
type: string
title: cloud platform
environment:
type: string
title: environment
resources:
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
image: vRA-Windows2019
customizationSpec: WIN2019_vRA
cpuCount: 2
totalMemoryMB: 4096
constraints:
- tag: '${input.platform}'
- tag: '${input.environment}'
networks:
- network: '${resource.Cloud_vSphere_Network_1.id}'
Cloud_vSphere_Network_1:
type: Cloud.Network
properties:
networkType: existing
I have assigned a tag to Network profile and tried in YAML under constraints, still same error.
Kindly help me understand the issue and the resolution.
Regards,
Sasidhar
Whoops, nope, I was actually overthinking that; the issue was just with the network resource not having the 'hostname' property defined at all - a null value rather than a collision. Remember that the naming template is applied at the resource (not deployment) level so all resources in a template (machine, network, etc) will get named.
So just add
properties:
hostname: '${input.hostname}'
to the network resource portion of your cloud template and I think you'll be good to go.
All together now:
formatVersion: 1
inputs:
hostname:
type: string
title: Server name
resources:
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
hostname: '${input.hostname}'
image: cent7
flavor: micro
networks:
- network: '${Cloud_vSphere_Network_1.name}'
Cloud_vSphere_Network_1:
type: Cloud.vSphere.Network
properties:
hostname: '${input.hostname}'
Maybe change the type of your network resource to Cloud.vSphere.Network so it matches the machine type?
Cloud_vSphere_Network_1:
type: Cloud.vSphere.Network
properties:
networkType: existing
What does your network profile in Cloud Assembly look like?
You might try changing the Isolation Policy of the Network Profile to "None" just to simplify things a bit. I don't think those options are involved when you use `networkType: existing` but it may just be adding unnecessary complication.
I'd also specify the CIDR with the network address (x.x.x.0/23) instead of a host address (x.x.x.66/23) just to make sure there isn't any confusion there.
The Provisioning Diagram from the deployment test might yield some additional insight into what's going on as well.
Hmm, I'm trying really hard to reproduce this in my lab but haven't had any luck in breaking it yet.
Any change if you remove the constraints section from the machine resource definition? Try to make the cloud template as simple as possible to rule out potential points of failure.
I figured out the issue is causing due to ${resource.hostname} given in the project under custom naming section.
Without network adapter the hostname was given as an input with ${resource.hostname} updated in project and the VM build was successful taking default VLAN.
As you suggested, tried from scratch without custom hostname and figured out the issue. Thanks for your help.
Is there any way we can give custom hostname without any predefined configured input values(Env, OS flavor, Suffix number etc) with a network adapter in Blueprint design. My customer do not have a naming convention for hostname in place.
For ex: I want to build a VM name as "Titanic".
Cool, I'm glad you were able to track down the source of the issue!
I did some testing with that information and was able to reproduce the same problem you had before; if I set the Naming Template on the Project to something like '${resource.hostname}' without including any randomized digits ('{###}'), there's a conflict because both the computer and network resource try to use the exact same name.
I was able to work around that by appending '-net' to the property on the network resource:
inputs:
hostname:
type: string
title: Server name
resources:
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
hostname: '${input.hostname}'
image: cent7
flavor: micro
networks:
- network: '${Cloud_vSphere_Network_1.name}'
Cloud_vSphere_Network_1:
type: Cloud.vSphere.Network
properties:
hostname: '${input.hostname + "-net"}'
I can now input a specific hostname to be used for the provisioned VM, and the associated network resource will get named the same but with "-net" tacked on the end.
Whoops, nope, I was actually overthinking that; the issue was just with the network resource not having the 'hostname' property defined at all - a null value rather than a collision. Remember that the naming template is applied at the resource (not deployment) level so all resources in a template (machine, network, etc) will get named.
So just add
properties:
hostname: '${input.hostname}'
to the network resource portion of your cloud template and I think you'll be good to go.
All together now:
formatVersion: 1
inputs:
hostname:
type: string
title: Server name
resources:
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
hostname: '${input.hostname}'
image: cent7
flavor: micro
networks:
- network: '${Cloud_vSphere_Network_1.name}'
Cloud_vSphere_Network_1:
type: Cloud.vSphere.Network
properties:
hostname: '${input.hostname}'
You're welcome. That was a kind of fun one!