Rewire a vm vcloud workflow changes the nic type to E1000 want it to be VMXNET3

[qc4vmware]

I am using the "Rewire a VM" workflow and it seems to modify the nic type to E1000.  I am not sure if I am missing an additional step to set the nic type or keep it from changing.  Can anyone point me in the right direction?  I want the end result to be the nic is set to VMXNET3.  Thanks!

Paul

[Jalapeno420]

I had a similar issue before.  A predefined workflow referenced the action "createVirutalEnternetCardNetworkConfigSpec" which uses VcVirtualPCNet32 instead of VcVirtualVmxnet3.  I had to duplicated the action, change PCNet32 to Vmxnet3 and repointed some workflows.  This might be a similar issue.

[Burke- · Accepted solution]

Hello Paul, I just did the following:

Setup a vApp with a VM that has a VMXNET3 nic setup. - confirmed that the NIC type displayed in vCD is VMXNET3 and in vCenter it is VMXNET3

Ran the "Wire a virtual machine network" workflow

Checked the vCD UI and see the same as you: E1000 for the type.. HOWEVER - in vCenter, it shows VMXNET3.

This looks like it may potentially be a display bug and/or API bug.

You should check your vCenter to see if you have same results as my test, and then submit an SR with VMware support.

[qc4vmware]

I did just confirm that the nic type is indeed set to VMXNET3 as far as vCenter is concerned.  Thanks once again!  I made the assumption that those two values would always be in sync.  Silly me

[qc4vmware]

So this is driving me kinda crazy again.  I feel like I am missing something when adding a nic to a vm.  If I deploy a vm which has no nic then attempt to add a nic either programtically or via the vCloud gui I can only seem to add a nic type of E1000.  Adding the nic in the gui if I click the check box to show the nic type and select VMXNET 3 from the pull down the nic type shown in vCenter is E1000.  The only time I can seem to get a VMXNET3 nic type to consistently show in both vCenter and vCD is if I run through the following steps.

1. Build the VM in vCenter with a VMXNET3 nic.

2. Import from vCenter into vCD.

3. Create a template.

4. Deploy the template.

5. Add additional nic.

When I do this if I add the nic programatically I get the mismatch of E1000 showing up in vCD but VMXNET3 showing up in vCenter.  If I add the additional nic with the vCD gui it shows as VMXNET in both spots.  If I delete both nics from the VM and create a new template  and deployt that template all the nics show as E1000 in vCenter even though I selected VMXNET3 from the drop down when I created it.  Any clue as to what is going on?  I did submit a  bug report but I want to make sure this is actually a bug and not programmer error of some sort.

I also tried copying the action for "createVirtualNetworkCard" and replaced:

var resourceSubType = new VclCimString();

resourceSubType.value = "PCNet32";

rasd.resourceSubType = resourceSubType

With:

var resourceSubType = new VclCimString();

resourceSubType.value = "Vmxnet3";

rasd.resourceSubType = resourceSubType

In relationship to the advice given in this thread hoping that would work to force it through.

[qc4vmware]

I hate to beat a dead horse but I still can't seem to find anyway of creating or modifying a network connection and forcing it to be anything but type E1000.  I had kind of forgotten about this since we have been struggling with all sorts of other vCloud related stuff + 5.1 upgrade nightmares.  Now I definitely only see E1000 showing after any clone or nic addition via orchestrator.  Through the vCD gui everything is fine but it is driving me mad with the api.  Is this a limitation or bug of some sort?

Oh... one new thing is we are also now using the latest virtual hardware if that makes a significant difference.