VMware Cloud Community
craigso
Enthusiast
Enthusiast
Jump to solution

Wrong VM network adapter gets assigned in vCenter

Hello,

Thank you for taking the time to read this thread. Our team is experiencing an issue where the network adapter in vCenter gets assigned incorrectly when provisioning a VM from vRA. Let me first explain the configuration, then I'll explain the behavior in depth.

We have a business group that is has only one reservation associated with it. That reservation is shown here:

pastedImage_0.png

As you can see there are two network profiles, which are only configured to use the network adapters that are associated with them in the reservation. Meaning, if the wrong adapter is assigned to the network, as you would expect, it won't be able to communicate.

From the vRA Blueprint side, have a custom property VirtualMachine.Network0.ProfileName that is displayed as a dropdown on the Blueprint. This is shown below with the values:

pastedImage_3.png

It's my understanding that if we assign the network profile, by name to this property is should provision an IP out of that range (which it does) and set the network adapter accordingly. The issue we are experiencing is that the VM receives and IP in the correct network range 100% of the time, but the network adapter almost randomly gets assigned between the adapters that are configured in the reservation. Meaning, in this case either the adapter ending TEST1_epg or TEST4_epg (shown above).

I have confirmed also that the we do have a vm customization spec defined. I had an issue with this previously and was able to fix with help from this community. (Thanks again!)

Please let me know if there is any additional information needed to help troubleshoot this issue. Our team is kind of at a loss regarding this behavior.

Reply
0 Kudos
1 Solution

Accepted Solutions
daphnissov
Immortal
Immortal
Jump to solution

What you probably need instead is the custom property VirtualMachine.Network0.Name with the value that must be *exactly* what's specified in the reservation. From there, the network profile associated with it should be used. This is probably the hold-up in your scenario, but yes, GSS should be able to help with this if you wanted to go that route. SDK support shouldn't be needed. BTW, you didn't mention your version, so what are you using?

View solution in original post

Reply
0 Kudos
6 Replies
craigso
Enthusiast
Enthusiast
Jump to solution

Is this the type of scenario that support can help with? We don't have SDK support at the moment, so our only option is the vRA support team.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

What you probably need instead is the custom property VirtualMachine.Network0.Name with the value that must be *exactly* what's specified in the reservation. From there, the network profile associated with it should be used. This is probably the hold-up in your scenario, but yes, GSS should be able to help with this if you wanted to go that route. SDK support shouldn't be needed. BTW, you didn't mention your version, so what are you using?

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

We were using VirtualMachine.Network0.Name previously with the getApplicableNetworks action to allow for the network to be selected from a dropdown. Post upgrade to our current version of vra 7.5 we are now receiving a 403 error when calling this action. That's a separate issue, no need to go into detail about that here.

I'll need to go back and try VirtualMachine.Network0.Name again, while manually specifying the value. I just don't know if VirtualMachine.Network0.Name will trigger the third party IPAM plugin (allocate workflow) like VirtualMachine.Network0.ProfileName does. That is an absolute requirement as well.

Going to go test your suggestion and the IPAM plugin now. Thank you for the feedback! I'll report back with my findings in a bit.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Not sure what your issue was with the getApplicableNetworks action, but it works as expected for me in my vRA 7.5 lab environment. I also can't comment about your custom IPAM plugin, but as long as the network name is set correctly and the network profile is matched to that network in the reservation, I see no reason why it shouldn't fire. What I see far more commonly (and have experience using most) is IPAM provided by various SovLabs modules (which support most commercial IPAMs out there). That's considerably easy to make work because you actually don't even need the built-in vRA network profiles at all, and those CAN be called easily everywhere, but that's another thing altogether...

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

I just finished testing this and you are correct, changing it from VirtualMachine.Network0.ProfileName to VirtualMachine.Network0.Name and specifying the adapter worked 100% of the time. Also this did in fact trigger the IPAM plugin allocate workflow as well. So a win on both accounts.

In regards to IPAM, we are a corner case. We are a university that develops an open source network documentation tool which includes IPAM. That being said, we had to develop a plugin using the IPAM SDK that connects to our IPAM solution. So far its been going pretty. We have a functioning plugin, although I'd call it an early beta. We'll continue to improve it over time. It's been a challenge to do without SDK support, but we've managed up until this point.

I'll create a separate thread detailing the issues with getApplicableNetworks.

I'm going to go ahead and mark your reply as the correct answer. Thank you once again!

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Good deal. When you create that separate thread on your action issues, copy-and-paste the action code so I can compare it to the stock.

Reply
0 Kudos