VMware Cloud Community
Steven1314
Enthusiast
Enthusiast
Jump to solution

Vmware 6.5 fails to assign an ip for a linux vm if the network adapter is invalid

  I am using vmware sdk to create a  linux vm(ubuntu) on vmware 6.5 by specifying a network adapter, which is an invalid value input wrongly.

The network adapter should be vmxnet3, but it is written as vmxnet 3. After the vm is created, I found the network adapter is not what is specified,

instead it is E1000. Besides, whenever I specify an un-existed network adapter to a vm, the vm will fail to get ip after it started.

  However, if I directly specify E1000 for a vm, it can successfully get an ip.

I want to know the root cause for this problem. Could anyone help me?

Reply
0 Kudos
25 Replies
Steven1314
Enthusiast
Enthusiast
Jump to solution

Thank you very much!

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Please have some patience - my nextreply will be quite long but I am working on it.


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Ok - lets go into details.

First of all we have to discuss "silent defaults" in a vmx-file.
Unfortunately this topic is completely undocumented so I can only speak from 15 years of experience.
Probably the easiest example for a silent default is the line

scsi0.present = "true"

A vmx-file may print this parameter but if it is missing it will be assumed that the value is "true".
So if you create a vmx-file from scratch you can skip this parameter if you want a VM with a SCSI-controller.
If you want a VM without a scsi-controller you must specify

scsi0.present = "false".

In the early days of ESXi there was only one virtual device available for scsi-controllers : buslogic

So there was no need to print that parameter.

So whenever you created a vmx-file you got a VM with

scsi0.present = "true"

scsi0.virtualDev = "buslogic"

Even if both lines are missing you still get a VM with a buslogic scsi-controller.

Early networkcards in ESXi and Workstation all used the virtualDev = "vlance"

This is a very outdated AMD PCnet32.

This device nowadays is only used by NT4, SCO, Win9x and other grandpa OS.

But as the vmx-syntax is backwards compatible the ethernet0.virtualDev parameter still silently defaults to "vlance"

And at this place I must confess that I made an error in one of my recent posts where I said:

> e1000 - uses a PCI-port - used as fallback for 64bit guests

The statement "used as fallback for 64bit guests" is very likely wrong. It would make perfect sense to do that but it would break the undocumented vmx-syntax rules.
So please forgive me if that statement confused you.
Maybe the ESXi-GUI sets
ethernet0.virtualDev ="e1000"

for all 64bit guests unless you specified some other type.

But as the creation of vmx-files is pretty inconsistent across the different platforms and versions lets go with what I know for a fact.
Also if I follow the vmx-syntax rules that I have discovered by myself the behaviour you see makes perfect sense.

Next thing you should be aware of are vmx-file parameters that are automatically added by the ESXi-engine if they are not present in the vmx-file.

Easiest example:

If you have

scsi0.present = "true"

scsi0.virtualDev = "lsilogic"

you will automatically get an additional parameter after first boot of the VM which specifies the pci-slotnumber.

scsi0.pciSlotNumber = "16"

The lsilogic scsi-parameter is a PCI-card.

Now it gets a little bit confusing for the newbie.

If you select a LSI-SAS controller this device needs a PCI-expresscard and when you print

scsi0.present = "true"

scsi0.virtualDev = "lsisas1068"

in the vmx-file you will see the additional parameter

scsi0.pciSlotNumber = "160"

after the first start.

Valid PCI-slots use the numbers 16, 17, 18 and so on.

Valid PCI-express slots use the numbers 160, 192, 224 and so on (add 32 to get the next valid number.)

So now that we have the basics for scsi-controllers lets see what we get with some examples.

If you write

scsi0.present = "true"

in the vmx file you will effectively get

scsi0.present = "true"

scsi0.virtualDev = "buslogic"

scsi0.pciSlotNumber = "16"

If you write

scsi0.present = "true"

scsi0.virtualDev = "buslogic"

scsi0.pciSlotNumber = "160"

you have an invalid configuration and ESXi will either complain or silently reset the pcislot-number to

scsi0.pciSlotNumber = "16"

In this case a new guestOS will be happy but an already installed guest may suddenly panic if it does not find the scsi-controller in the slot it used last time.

In the early days there was no need to specify PCI-slots in the vmx-files. You only run into problems if you assigned more than 5 PCI-cards.

If you assigned 4 scsi-controllers plus 2 networkcards ESXi complained because you exceeded the available number of 5 slots.

Nowadays we can have PCI-slots and PCI-express slots and the number of available slots is so high that it is almost impossible to assign more slots than available.

Networkcards also come in both vrainats:

vlance, vmxnet and e1000 use a PCI-slot (valid slot numbers 17, 18 ,,,,

vmxnet3 and e1000e use PCI-express slots (valid slot numbers are 192, 224 ....)

Now let me sum up the vmx-syntax rules a la sanbarrow - see my site sanbarrow.com - a bit outdated as I have to admit ...

There are 4 types of vmx-parameters:

mandatory parameters: - the vmx-file will be invalid if these parameters are missing or invalid

optional parameters - the device will be created if the parameters are valid

silent defaults - this parameters will be used wether you write the parameter or not (example scsi0.present = "true"

dependant parameters - this parameters will be automatically added to the vmx-file if they are missing,

1. mandatory parameters

config.version = "8"

virtualHW.version = "7"

guestOS = "winxppro"

You must add those to get a working VM compatible with ESX 4 or Workstation 6.5

For recent versions you need at the very least

.encoding =

config.version =

virtualHW.version =

guestOS =

If one of the parameter is missing the vmx-file will not be accepted.

2. normal parameters - examples:

scsi1.present = "true"

ethernet0.present = "true"

This group contains all the parameters you should add if you create a vmx-file from scratch or when you try to find errors in an existing file

3. silent defaults - examples:

scsi0.present = "true"

scsi1.present = "false"

ethernet0.present = "false"

scsi*.virtualDev = "buslogic"

ethernet*.virtualDev = "vlance"

Rule of thumb: allways write this parameters to make troubleshooting easier. Exception: *.present = "false" - no need to manually disable devices.

4. dependant parameters - examples:

*pciSlotNumber =

ethernet0.address =

uuid.*=

nvram =

pciBridge*.* =

...

List is not complete ! This parameters will be added automatically. Only set them manually if you really really know what you are doing !

If you assign values manually you can produce working VMs but the guestOS maybe puzzled if the pci-slots are not those, it remembered from last successful start.

Ok - now lets return to your original question.

To create a new VM with a networkcard make sure you have

ethernet0.networkName =

ethernet0.virtualDev =

ethernet0.present =

To create a SCSI-controller use

scsi0.present =

scsi0.virtualDev =

If you do not specify

ethernet0.virtualDev assume that you will get the outdated "vlance" - which will work with old guestOS only.

If you do not specify

scsi0.virtualDev =assume that you will get the outdated "buslogic" - no modern guest will have drivers for this device.

Ok -that will have to be enough for now.

Lets look at your vmx-file:

Now you have:

ethernet0.address = "00:50:56:08:3F:F5"

ethernet0.addressType = "static"

ethernet0.networkName = "VM Network"

ethernet0.pciSlotNumber = "32"

ethernet0.present = "TRUE"

as you did not specify virtualDev I assume your VM will effectively use

ethernet0.address = "00:50:56:08:3F:F5"

ethernet0.addressType = "static"

ethernet0.networkName = "VM Network"

ethernet0.pciSlotNumber = "32"

ethernet0.present = "TRUE"

ethernet0.virtualDev = "vlance"

Ubuntu 64 has no driver for the 32bit AMD PCnet card so it will not be able to receive an IP.

By the way - using a LiveCD for troubleshooting is a smart decision.

This way changing the vmx-file will have the expected results.

If you use a normal Ubuntu 64 VM troubleshooting is way more involved.

Now remove all your ethernet0.parameters and just use:

ethernet0.networkName = "VM Network"

ethernet0.present = "TRUE"

ethernet0.virtualDev = "e1000"

I bet 10 dollars that this VM will receive an IP

Ulli

_______________________________________________________________________________________________________

"Did you find this helpful? Let us know by completing this survey (takes 1 minute!)"


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
Steven1314
Enthusiast
Enthusiast
Jump to solution

It works when I did according to what you said. I come to know the root cause for the problem now and learn a lot from you.

Thank you very much for your detailed explanation!

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

So do you confirm that ESXi 6.5 assigns the outdated "vlance" if you do not specify ethernet*.virtualDev ?


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
Steven1314
Enthusiast
Enthusiast
Jump to solution

  Though I could not directly confirm that ESXi 6.5 assigns the outdated "vlance" if ethernet*.virtualDev is not specified explicitly, I try to change the value of  ethernet*.virtualDev from "vlance" to another one "VMXNET 3" and finally the vm fails to start up. So I think you are right.

  Thank you again, my friend!Smiley Happy

Reply
0 Kudos