9 Replies Latest reply on Aug 21, 2019 10:57 PM by continuum

    new-vm without networkadapter on standardswitch

    komar09 Lurker

      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

        • 1. Re: new-vm without networkadapter on standardswitch
          lmoglie Enthusiast
          vExpert

          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

          1 person found this helpful
          • 2. Re: new-vm without networkadapter on standardswitch
            continuum Guru
            User ModeratorsvExpertCommunity Warriors

            > 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

             

            • 3. Re: new-vm without networkadapter on standardswitch
              komar09 Lurker

              hi, continuum,

               

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

              Thank you for the hint.

               

              regards

              Artur

              • 5. Re: new-vm without networkadapter on standardswitch
                LucD Guru
                User ModeratorsCommunity WarriorsvExpert

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

                • 6. Re: new-vm without networkadapter on standardswitch
                  continuum Guru
                  vExpertUser ModeratorsCommunity Warriors

                  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.

                  • 7. Re: new-vm without networkadapter on standardswitch
                    LucD Guru
                    Community WarriorsUser ModeratorsvExpert

                    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.

                    • 8. Re: new-vm without networkadapter on standardswitch
                      komar09 Lurker

                      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.

                       

                      • 9. Re: new-vm without networkadapter on standardswitch
                        continuum Guru
                        Community WarriorsvExpertUser Moderators

                        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