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?
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!)"
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.
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?
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!
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.
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!
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?
> 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
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.
So don't specify an invalid adapter type and problem solved
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.
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.
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?
This behavior not only confuses we developers but also our customers. They ask continuously why this e1000 fails to help get an IP?
Attach an example vmx-file !
It makes no sense to fish in the mudd any longer.
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"
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 ?
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.
Could you please tell me how to upload files here?
Really appreciate that!
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.