Link to home
Start Free TrialLog in
Avatar of compdigit44
compdigit44

asked on

ESXi 5.1 vDistributed Switches

I am trying to make sure I understand how things actually working in VMware instead of doing things like a mindless robot.

1) When you create a new vDS you can increase the number of ports without rebooting any of the host. Yet, if you do the same action after the vDS is created to need to reboot the host. Why is this?

2) When you create a VDS uplink I understand this is the physical nic on all of your host but do they have to all be in the same slots on the servers as best practice? Am I correct that if you want to make host / nic specific changes, you need change the settings on the host and cannot do this through the vDS settings.

As you can see I am a bit fuzzy on the vDS uplink concept even though I have used them but used them only doing this by habit..
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

1. Good Question, I'd never really thought about WHY, other than, a restart is required, it's actually the same for a vSwitch, how many times have you been caught out because you've exceeded the number of portgroups on a vSwitch, e.g. exceeded the default, you can increase the number, but it does not take effect UNTIL after a reboot.

- I'll try and get an answer for you!

2. No, they do not have to be in the same slot, any vmnic can be added to a vDS. BUT we try an ensure, that it's best practice to have all your network interfaces in the same slots, with ALL your servers, to ensure, they Are all indentical, this then helps to maintain vmnic3, is the same vmnic3 on ALL your servers. (otherwise it's very difficult to work out nic numbering!). Only today, I was removing network interface cards from servers and enuring the Cluster had the same nics, in the same slots throughout, and all the nics were the same, and all the cabling was the same.

It's quite a large job even with the smallest 20 servers in a cluster, and 12 nics per server, that's alot of cables!
Avatar of compdigit44
compdigit44

ASKER

Hancock my friend I was hoping you would chim in on my question.

1) I am interested to see what you find out with my first questions. It may be one to pass along to VMware. I was one of these annoying kids growing up who always asked why..LOL!!!

2) Just to be clear the vDS allows for the central managed of Switchs/ Nic from a central console. but does it all you to make network card specific changes on one server only though.

Do you placed you management network on a vDS or standard switch? I have see arguments for both sides of this issue.
1. try and find out the answer....

2. what network changes do you want to do?

vDS or VSS, depends on your practice, many do either, and some prefer to use VSS for VMKernel Traffic and iSCSI, and use VDS for ALL VM traffic.
Here is where my problem lies. I do not have full admin rights in vCenter which our VMware admin is the only person who does. I cannont test thing myself. I guess in someway I have always had a hard time grasping the concept that the vDs and manage physical nic on host in the cluster.

On a side note, for the longest time I have been searching of an online VMware training lab that would allow me to test these types of things myself. It's to bad Experts-Exchange doesn't have an online virtual lab environment. I would even pay extra for something like this.
Hi Hancock, I was wondering if you had any further insight on vDs..
I'm at a VMware gathering tomorrow, so I'll ask VMware Engineers for their take on this!
Thanks a Million...
ASKER CERTIFIED SOLUTION
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
This is a good thought, but here is my question in return if this is turn that a host only read the config on boot then why when you build a new vDS and increase the port above the normal amount you are able to on the fly without a reboot.

Also, I have a suggestion for E.E: It would be nice if the had a disposable lab environment paying members could use for a fee
yes, because the config, is only written on shutdown of host! e.g. commited to disk. So up and till that point it would be changed...

Waiting for an Official Answer!

Off-topic but why not use www.baremetalcloud.com, like we do!

It only costs you a few dollars, and then you can turn off, and store your images, and it does not cost you!
So if I am understanding what you are saying correctly. When you create / make changes to a vDS that changes are only made to the "running" config and are not really in effect until the host is rebooted???

Starting to get a little confused here. I look forward to hearing what VMware has to say on this.

That's for the tip on the lab environment I have never heard of it before. How does it compare with labslice.com?
Host changes are only written at shutdown.

To be honest I do not think anybody really knows because its never been asked.

And that's how the product is designed to works.
I have been giving this a lot of thought. Are you saying that if I were to change the change the ports on the vDS from 120 to 200 I could to this while the server is running and would not be prompted to reboot but if I were to boot a new VM that would create port 121 the VM would fail to connect to the network because only 120 ports would only still be in use by the server?

Is there a why to compare a host running config vs saved config????
I believe any change made to the configuration, after the initial configuration needs a reboot, for those changes to take effect.

I believe this information is stored in /etc/vmware/esx.conf

and If you change anything in that file, using vi, it does not take effect until you reboot.

e.g. just a change of vmnic1 to vmnic 21, it needs a reboot.