VMware Cloud Community
komar09
Contributor
Contributor
Jump to solution

new-vm without networkadapter on standardswitch

Hello,

I am trying to create a new vm without any netwokadapters.

   New-VM -Name 'VM1' -vmhost $hostobj -Datastore $dsobj -NumCpu 4 -MemoryMB '2048' -DiskMB '40960'

This works fine as long as I do it in a cluster with vdSwitches only.

If there is a Standard-Switch present the same command creates a VM with a e1000 networkadapter maped to the vSwitch0.

is there something I am dong wrong? Did I miss something? Is there a way to make this not happen?

Any hints?

Thank you all

Yours faithfully

Tags (2)
Reply
0 Kudos
1 Solution

Accepted Solutions
LucD
Leadership
Leadership
Jump to solution

Hi Ulli,
Afaik, these HW defaults follow a set of hidden rules.

The only (supported) way to get exactly what you want is to use a template when creating a new VM.
A template doesn't necessarily need to have the guest OS to be installed, just configure the HW of your desired model VM.

Creating a VMX file from scratch, or better said, replacing a VMX with one's desired HW config, is another option.

But this method is more cumbersome imho, and in some ways might jeopardize one's support.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

View solution in original post

Reply
0 Kudos
9 Replies
lmoglie
Enthusiast
Enthusiast
Jump to solution

Hi,

I had the same problem too. The only way I found was to create the VM and remove the NetworkAdapter at the same time ...

Remove-NetworkAdapter -NetworkAdapter (Get-NetworkAdapter -VM $(New-VM -Name "VM" -ResourcePool "CLS")) -Confirm:$false

Please consider marking this answer "correct" or "helpful" if you think your query have been answered correctly.

Cheers,

LM

continuum
Immortal
Immortal
Jump to solution

> Did I miss something? Is there a way to make this not happen?

I have a theory that would explain the behavior - have not tested it but it makes perfect sense to me ....

The virtal hardware for a VM will be created at the first start of the VM.

The instructions for each different VM will be read from the vmx-file.

And now comes the point that you may not be aware of ....

The syntax for the vmx-file uses what I call "silent defaults"

The probably best known example for a "silent default" is this one:

scsi0.present = "true"

This means that the behaviour is: always create new VMs with a SCSI-controller unless the instructions in vmx read as

scsi0.present = "false"

As far as I know there is no official documentation for silent defaults and the values have changed over the years.

To explain the behaviour you see the following assumptions make perfect sense to me:

ethernet0.present = "true"

The value for ethernet0.virtualDev depends on the guestOS parameter so for your selected guestOS we can assume another silent default to be:

ethernet0.virtualDev = "e1000"

We can also assume that

ethernet0.addressType = "vpx"

is another one.

So we have 3 rules to apply when creating a new ESXi VM with guestOS-type you selected:

ethernet0.present = "true"
ethernet0.virtualDev = "e1000"

ethernet0.addressType = "vpx"

So the behaviour will be:

you always get one networkcard when creating a new VM unless you explicitely disable it by setting ethernet0.present = "false"

for the guestOS you selected you will always get an e1000 unless you order a different one.

ethernet0 will be always mapped to vSwitch0 unless specified otherwise.

Now ESXi has all the info to fill the other ethernet0 parameters automatically - like mac address and so on.

Next your VM boots and will create an unexpected ethernet device.

If the VM boots in an environment that has a vSwich0 all parameters are valid and you will see a functional nic inside the VM.

If the VM boots somewhere where no vSwitch0 exists - for example in your case with distributed switches only - then I would expect that you get a VM with no working nic.

Not sure if ESXi disables an ethernet device if there is no backend - it may also allow such a config - but then you would get a phantom nic in the  registry of a Windows VM.

If it works like this it would prefectly explain why the suggested workaround is supposed to work

It also explains why you an obscure behaviour if you use procedures that create a vmx-file using a newer scripted procedure.

The vmx-syntax rules need to be consistent across versions and need to be backward compatible.

The result is the behaviour you see:

when using scripts to create a new VM you expect to get NO device unless you order one.

following vmx-syntax rules the same assumption would work in most cases:

you get NO USB-port unless you order one

you get NO second nic unless you order one.

... and so on ...

BUT here we have a few exceptions where the logic is reversed:

you get the first SCSI-controller unless you explicitely say that you dont want one.

you get the first ethernet-controller unless you explicitely say that you dont want one.

I may be totally wrong with this theory - but for me it makes sense.

You should be able to test this with some examples ...

Ulli


________________________________________________
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
komar09
Contributor
Contributor
Jump to solution

hi, continuum,

this sounds promising. I think I'll take some time to test this.

Thank you for the hint.

regards

Artur

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Discussion moved from VMware vSphere™ to VMware PowerCLI

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

What continuumsaid, there are no such (hidden) defaults in PowerCLI.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Hi Luc

thats what I thought.

But knowing that does not help the user in this case.

Do you think my theory is nonsense ?

I would really like to see a brand new vmx file created like discussed  in this example.


________________________________________________
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
LucD
Leadership
Leadership
Jump to solution

Hi Ulli,
Afaik, these HW defaults follow a set of hidden rules.

The only (supported) way to get exactly what you want is to use a template when creating a new VM.
A template doesn't necessarily need to have the guest OS to be installed, just configure the HW of your desired model VM.

Creating a VMX file from scratch, or better said, replacing a VMX with one's desired HW config, is another option.

But this method is more cumbersome imho, and in some ways might jeopardize one's support.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
komar09
Contributor
Contributor
Jump to solution

Hello,

..and in some ways might jeopardize one's support..

in that case, the easiest way to meet my requirements seems to be to just remove the created adapter.

The use of templates does not fit the environment.

Thank you.

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

WARNING - OFFTOPIC ...

> The only (supported) way to get exactly what you want is to use a template when creating a new VM.

Support-policy ??? - oh dear - dont remind me.

Last weeks I thought about that a lot ....
and it took me a lot of effort to resist writing a long speech here.I always assumed that "a long term happy user needs to understand the basics - so lets explain that as good as possible" would obviously be a major part of any reasonable support policy.
What a silly assumption !
My long term observations of the results of the VMware support policy allow only one conclusion.
The early decision to avoid documentation of vmx and vmdk stuff and get away with that 
by providing a solid and easy interface that will handle all tasks was contraproductiv.
This post is an example: in this case the promised interface does not give the expected results.
A user without indepth vmx and vmdk howto has a hard time to understand what the problem is.
A user with that knowhow looks at the problem and understands why this had to happen and can work with this at once.
One more drastical example you very very likely also noticed yourself.
A user with missing vmdk knowhow sees that the GUI displays a file named name-flat.vmdk.
The user thinks something serious is wrong and then draws an understandable but completely missguided conclusion
and deletes that obscure flat.vmdk.
So does that policy really helps any involved party in the long run ?


Ulli


________________________________________________
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