Highlighted
Expert
Expert

What is doing Set-NetworkAdapter cmdlet ?

Jump to solution

Hi all,

  i got a question regarding set-networkadapter , For example i wanted to change a e1000 adapter to vmxnet3.

so from manual:

-Type <VirtualNetworkAdapterType>
    Specify the type of the network adapter. The valid types are e1000, Flexible, Vmxnet, EnhancedVmxnet, and Vmxnet3, and Unknown.

But windows (2008r2) seems not to recognize the change. Any idea how come ? get-networkadapter shows that this is not vmxnet3, but windows shows that this is intel nic.

--- @blog https://grzegorzkulikowski.info
0 Kudos
1 Solution

Accepted Solutions
Highlighted
User Moderator
User Moderator

And did you try it with the VM powered off ?

I think the VM needs to be powered off to change the NIC Type.


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

View solution in original post

0 Kudos
18 Replies
Highlighted
User Moderator
User Moderator

Is the VM poweredoff when you change the NIC type ?


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

0 Kudos
Highlighted
Expert
Expert

it's still poweredon.

--- @blog https://grzegorzkulikowski.info
0 Kudos
Highlighted
User Moderator
User Moderator

And did you try it with the VM powered off ?

I think the VM needs to be powered off to change the NIC Type.


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

View solution in original post

0 Kudos
Highlighted
Expert
Expert

It's like you said Luc. But i am surprised with the result. When vm is powered off, set-networkadapter to different type acts in the same way like when vm is powered on(no errors as well). When the vm will be powered up after, all network information is lost.

I am just wondering if this infrmation shouldn't be put into the manual , i mean how come should i know that this action will clear my network information, or how come in powercli it does not throw any error when vm is powered on ? Maybe help for this cmdlet should be updated, it leaves to many things open, does not say in front that:

1. please shut down vm first, if should say : invalid vm state when it's powered on

2. big sign that this will make the interface to loose network config .

Thx Luc.

--- @blog https://grzegorzkulikowski.info
0 Kudos
Highlighted
User Moderator
User Moderator

I agree, the cmdlet should be a bit more user friendly, and the conditions and effects should be mentioned in the help.


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

0 Kudos
Highlighted
Immortal
Immortal

Thanks for the notice guys. We'll take care to update the documentation as needed.

Highlighted
Expert
Expert

Thanks Iva!

--- @blog https://grzegorzkulikowski.info
0 Kudos
Highlighted
Immortal
Immortal

Grzesiekk,

Some more info is required in order to reproduce the issue:

1. What's your VC version?

2. What's your PowerCLI version?

3. What's the hardware version of the VM?

4. What are the lost settings?

5. Is it correct that you are trying to perform an e1000 to vmxnet3 transformation?

Thanks,

Iva

0 Kudos
Highlighted
Expert
Expert

VC 5.0.0 build 755629

PowerCLI Version
----------------
   VMware vSphere PowerCLI 5.0.1 build 581491
---------------
Snapin Versions
---------------
   VMware AutoDeploy PowerCLI Component 5.0 build 544967
   VMware ImageBuilder PowerCLI Component 5.0 build 544967
   VMware vCloud Director PowerCLI Component 1.5 build 581492
   VMware License PowerCLI Component 5.0 build 544881
   VMware vSphere PowerCLI Component 5.0 build 581435

VM version 7

If this operation is done while vm is powered off, windows acts in the way as it would found a new network card, hence ALL network settings regarding that old e1000 are not there.

e1000 -> vmxnet3

--- @blog https://grzegorzkulikowski.info
0 Kudos
Highlighted
Immortal
Immortal

Thanks for the quick reply.

Have you tried the same operation with the latest build of PowerCLI? If you've been able to reproduce the issue with the latest build, we'll investigate further. Up to now, using PowerCLI 5.1R1 we haven't been able to reproduce the issue. If the problem is only reproducible in earlier versions of both PowerCLI and VC, the options for fixing or documenting it are limited.

0 Kudos
Highlighted
Expert
Expert

Sure thing Iva, i will test that using newest release of powercli and get back to you with feedback

--- @blog https://grzegorzkulikowski.info
0 Kudos
Highlighted
Immortal
Immortal

Thanks! Smiley Happy

0 Kudos
Highlighted
Immortal
Immortal

Hi Grzesiekk,

Did you have the chance to check this? Smiley Happy

0 Kudos
Highlighted
Expert
Expert

Yes,

i have installed latest powercli. On windows 2008 r2, while vm was powered on i have added an e1000 nic, then i used set-networkadapter cmdlet to convert it to vmxnet3. Command ran without issues, in the system e1000 is still present even after reboot. It's the same behaviour when previous version of PowerCLI was used.

In the configuration of vm, when you look at edit settings, that nic is presented as vmxnet 3. But OS is not noticing this fact.

I also made a test on a vm which is powered off. The same results as previously. Nic is changed to vmxne3, OS recognizes it as a new vmxnet3 nic, and it defaults the settings to use the DHCP.

If you are having different results, can you share how are you doing this ? Maybe i am testing it in wrong way ?

Greg

--- @blog https://grzegorzkulikowski.info
0 Kudos
Highlighted
Contributor
Contributor

"Up to now, using PowerCLI 5.1R1 we haven't been able to reproduce the issue."

If this is the case please post your exact procedure as I can repeat the same results as the poster consistently....with this version.

Thanks

0 Kudos
Highlighted
Contributor
Contributor

Hello Everyone,

I am having the same is in 2012 R2. This  script I ran in powercli 5.5 release 1, connect-viserver XXXXX, ran the script  get-vm camakrxxx | Get-NetworkAdapter | Set-NetworkAdapter -Type Vmxnet3 when the vm is on.
When I reboot the vm the ip configure is still there. But when i shut down the vm ..all  the ip configure is gone.  I want to keep the ipconfig and do not work to input 1000's ip.

The reason I am doing this is because

This is known issue affecting ESXi 5.1 and the workaround
for now is to use "vmxnet3" adapter. Please review below article for
more details :

  http://kb.vmware.com/kb/2059053

I have esx1 5.1.0, 1312873. and vcenter server version 5.1.0 build 1364037. This is  work around by vmware ..cause the e1000 nic is causing a purple screen.. So the work around is to change the vm nic to vmxnet3.

Any help or scripts would be helpfu...Thank you everybody.. I am sure lots of people have the same issue. i am in the process to open a case with VM..

0 Kudos
Highlighted
Contributor
Contributor

Unfortunately I don't think there is any way around losing the ip info. As far as Windows goes it is a new adaptor and it must change its drivers. Personally(I am dealing with the same problem....x14000) I am writing an app that will drop itself on the server, grab the IP info, wait for the change, and then re-apply it. Email me and when its done (in the next few days) I'll send you a copy.

Now for my real feelings on how VmWare is handling this and how it has cost them or is costing them many customers...maybe/probably me included. Hyper-v is free with Windows now and works well. WHY do you not care to fix this bug. You are NOT the tiny company anymore. Your clients/customers rely on this critically. How dare you just make a statement that you know of the bug and tell us to change the adaptor. Do you have any idea how much of a problem it is to have your entire prod environment crash every other week only for the vendor causing it to tell you to basically deal with it.

Well I will tell you that if I have to touch 14k servers, I might as well touch them all the way over to hyper-v. The manner in which this is being handled is down right irresponsible.....especially since I work for a company that provides critical infrastructure services to the entire world!

So...when are you going to fix this VERY problematic bug? Can we at least get an ETA? Are you working on it? Tell me something other than change every adaptor in my organization or deal with purple screens several times a month! E1000 is the DEFUALT STILL. When you created a guest you get an e1000 nic (for win at least) so your default is basically setting everyone up for failure.

0 Kudos
Highlighted
Contributor
Contributor

Thanks for that email.. That is just how i felt.. Vmware fix the issue with the following release.. Thank you Ken. On to patching the ESXi host...

    

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=206231...

0 Kudos