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