Solved: Re: Vmware 6.5 fails to assign an ip for a linux v...

Steven1314 · ‎05-20-2019

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?

continuum · ‎05-22-2019

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 ...

View solution in original post

daphnissov · ‎05-21-2019

Well, how would you get an IP on an interface that uses an invalid network adapter type? E1000 is a valid network adapter type. vmxnet3 is a valid network adapter type. Anything else falls back to e1000 as the default type. If you don't specify a valid type, your VM won't work. Pretty simple, I'd say.

------------------
How to Ask for Help on Tech Forums
https://neonmirrors.net

Steven1314 · ‎05-21-2019

Thank you very much!

Well, I would like to make it clear that what you said to some extent is right. Actually, it does fall back to e1000 when I try to specify an invalid network adapter named “VMXNET 3”(Attention: there is a blank character!)

But the problem is that the vm failed to get a IP after everything is correctly configured. As is known to us all, it should have got a IP. What makes it even weird
is that the network adapter shown on esx server for this linux vm is e1000.
Finally, I found that if the network adapter of the vm is switched to another one, say e100e then changed back to e1000, it can help get a IP for this linux vm.

So this is my question: why it is that? What is the root cause? Or it is an issue existed on esx server?

Steven1314 · ‎05-21-2019

The esx server I use is 6.5. And on this UI, we can see that it lists all the supported network adapters such as E1000, E1000E, VMXNET 3. But VMXNET3 shown on UI is "VMXNET 3(there is a blank character here)".

I want to know which value is correct? VMXNET3 or VMXNET 3 ？

Thank you very much!

daphnissov · ‎05-21-2019

The form "VMXNET3" is correct to refer to this. In programmatic syntax, spaces are rarely if ever allowed to exist in part of a config element name, so what you're seeing appears to be consistent with that. So, to summarize, if you don't specify the adapter type in a valid format, it'll fall back to e1000 as the default or just fail altogether. I don't know if this is a "bug" more so than a conscious design decision.

------------------
How to Ask for Help on Tech Forums
https://neonmirrors.net

Steven1314 · ‎05-21-2019

But even though it falls back to e1000, it still fails to get a ip ? I have to first switch the network adapter to another one, say "E1000E", then change it back to E1000, then restart the vm. Only when we do this can we get a IP? So do you think it is reasonable for this case?

Thank you very much!

daphnissov · ‎05-21-2019

What if you specify e1000 correctly on the first try (so it doesn't fall back)? Does it still fail to get an IP? Or does it only fail if you've supplied the wrong adapter type and therefore it has to fail back to e1000?

------------------
How to Ask for Help on Tech Forums
https://neonmirrors.net

continuum · ‎05-21-2019

> But the problem is that the vm failed to get a IP after everything is correctly configured. As is known to us all, it should have got a IP.

??? ... no comment ...

I wonder why you ask such a question without attaching the vmx-file and the vmware.log.

Anyway - you seem to be unaware of some details ....

Valid options for

ethernet0.virtualDev =

are:

vlance - oldest option - uses a PCI-port- used as fallback for 32bit guests

vmxnet - uses a PCI-port

vmxnet2 - uses a PCI-port

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

vmxnet3 - uses a PCIexpress port

e1000e - uses a PCIexpress port.

If you change the parameter for virtualDev so that a different pci-port is required the guestOS may assume the previous interface is just out to lunch and will come back one day.

So when ever you change virtualDev after the initial creation of the VM make sure you completely remove all ethernet*.parameters - otherwise you will get unpredictable results.
In Windows VMs you will see phantom nics - in Linux VMs you will get similar effects - check udev and network rules for further troubleshooting

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

Steven1314 · ‎05-21-2019

Thank you very much for your reply!

If I specify e1000 correctly on the first try, there is no problem to get an IP. The problem only happens when an invalid network adapter is specified.

So I am definitely confused about this case.

daphnissov · ‎05-21-2019

So don't specify an invalid adapter type and problem solved

------------------
How to Ask for Help on Tech Forums
https://neonmirrors.net

Steven1314 · ‎05-21-2019

Yes, I know a valid network adapter will bring no issue. Now that esx server falls back on default e1000, it should make it work normally, right? But there is a problem here!

Well, I am working on vmware related development. I am trying to use the sdk the vmware official provides to develop a product to create vm on esx server. Now I come into a dilemma when customers of my product try to input an invalid network adapter to create a vm on esx server.

I just want to look into it to figure out the cause. Hope you can understand me.

daphnissov · ‎05-21-2019

Yes, I understand, but the fact is when you're interfacing with an app in a programmatic fashion, you have to provide the correct inputs. If you don't, things won't work. There is not much you can do about that once it leaves your code, so the focus in your code should be some checks and input validations that would prevent a user from selecting an invalid network adapter type. There's not much more than can be said about this topic.

------------------
How to Ask for Help on Tech Forums
https://neonmirrors.net

Steven1314 · ‎05-21-2019

I can't agree more on what you said! Thank you again for your reply.

I don't understand the difference you know. If the esx server help us fall back on a default network adapter e1000, it can not work. However, it works well when we specify e1000 by ourselves. Why there exist such a difference? Shouldn't it be consistent with each other on behavior?

Steven1314 · ‎05-21-2019

This behavior not only confuses we developers but also our customers. They ask continuously why this e1000 fails to help get an IP?

continuum · ‎05-22-2019

Attach an example vmx-file !

It makes no sense to fish in the mudd any longer.

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

Steven1314 · ‎05-22-2019

The config below is the details about the vm newly created:

.encoding = "UTF-8"

config.version = "8"

virtualHW.version = "13"

nvram = "AVM_Esx_Test_0689e229-9929-42dc-9836-7d0e0938d6c4.nvram"

pciBridge0.present = "TRUE"

svga.present = "TRUE"

pciBridge4.present = "TRUE"

pciBridge4.virtualDev = "pcieRootPort"

pciBridge4.functions = "8"

pciBridge5.present = "TRUE"

pciBridge5.virtualDev = "pcieRootPort"

pciBridge5.functions = "8"

pciBridge6.present = "TRUE"

pciBridge6.virtualDev = "pcieRootPort"

pciBridge6.functions = "8"

pciBridge7.present = "TRUE"

pciBridge7.virtualDev = "pcieRootPort"

pciBridge7.functions = "8"

vmci0.present = "TRUE"

hpet0.present = "TRUE"

numvcpus = "2"

memSize = "2048"

floppy0.fileName = "floppy0"

ide0:0.deviceType = "cdrom-image"

ide0:0.present = "TRUE"

ethernet0.networkName = "VM Network"

ethernet0.addressType = "static"

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

ethernet0.present = "TRUE"

displayName = "AVM_Esx_Test_0689e229-9929-42dc-9836-7d0e0938d6c4"

annotation = "VirtualMachine Annotation"

guestOS = "ubuntu-64"

uuid.bios = "56 4d 91 e6 b8 8a b9 30-53 ce 98 d0 38 5b 21 c8"

uuid.location = "56 4d 91 e6 b8 8a b9 30-53 ce 98 d0 38 5b 21 c8"

vc.uuid = "52 c3 7d e2 20 17 fc 6b-a1 0e 5b 8e 0e f5 87 04"

ide0:0.fileName = "/vmfs/volumes/59946451-99f497e8-f63a-801844e2fe2e/image-livecd-f7118c45-76c2-404b-b2d7-9391774d8275.iso"

numa.autosize.vcpu.maxPerVirtualNode = "2"

numa.autosize.cookie = "20001"

sched.swap.derivedName = "/vmfs/volumes/59946451-99f497e8-f63a-801844e2fe2e/AVM_Esx_Test_0689e229-9929-42dc-9836-7d0e0938d6c4/AVM_Esx_Test_0689e229-9929-42dc-9836-7d0e0938d6c4-bdc3bf6c.vswp"

migrate.hostlog = "./AVM_Esx_Test_0689e229-9929-42dc-9836-7d0e0938d6c4-bdc3bf6c.hlog"

pciBridge0.pciSlotNumber = "17"

pciBridge4.pciSlotNumber = "21"

pciBridge5.pciSlotNumber = "22"

pciBridge6.pciSlotNumber = "23"

pciBridge7.pciSlotNumber = "24"

ethernet0.pciSlotNumber = "32"

vmci0.pciSlotNumber = "33"

vmci0.id = "945496520"

monitor.phys_bits_used = "43"

vmotion.checkpointFBSize = "4194304"

vmotion.checkpointSVGAPrimarySize = "4194304"

cleanShutdown = "TRUE"

softPowerOff = "FALSE"

tools.remindInstall = "TRUE"

continuum · ‎05-22-2019

That vmx-file is either truncated or it has been manually edited by someone who does not know enough about vmx-syntax.

Which option applies ?

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

Steven1314 · ‎05-22-2019

Well, this file is absolutely the original one from esx server datastore, I swear. So I habour reservation about your doubt.

I should have uploaded the file instead of pasting the content of it, but it seems that there is not way for me to do so.

Steven1314 · ‎05-22-2019

Could you please tell me how to upload files here?

Really appreciate that!

continuum · ‎05-22-2019

You can use the attach function.

And by the way sometimes the webgui also creates poor vmx-files.

I am in a hurry now but I will explain in depth once I am back.

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

All

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