1

We are implementing a vSphere farm and are using a distrubuted switch. The VC is a VM within the farm connected to the distrubuted switch. We had a SAN issue and all of our VMs were down. When the SAN recovered and we restarted the ESX host containing the VC the VC couldn't connect to the network through the vDS. We had to remove a NIC from the vDS on that host and create a regular vswitch and then connect the VC to that before the VC would connect to the network.

Is this typical behavior? If the VC goes down does all vDS networking stop on all the hosts? That seems to be a very bad thing. I thought networking would work even though the VC is down because the hosts have the vDS configuration cached. Is there a better way to configure it to prevent this from happening. We want to keep the VC as a VM for HA and recoverabilty purposes. Can anyone offer suggestions or explanations?

I appreciate the help.

Thanks,

Rick

2 Answers 2

0

The issue in your case was that the ESX host had to reboot without VC being available. My understanding of dVswitches behaviour is that depending on the port mode the vCenter server may not be able to attach to the dVswitch when it starts up because vCenter needs to handle this change to the dVswitch. In the scenario that you describe I'd expect the restart to work if the port is statically bound but if it has been configured to be ephemeral or dynamic I'd expect it to cause this sort of problem. I could be wrong though and it might always be a problem - I have never tried to replicate precisely what has happened to you.

Whether your particular issue might work or not there are scenarios where you will end up in trouble with vCenter on a dVswitch. If you want to move vCenter around using cold migration, or use a P2V or V2V to move a vCenter into an ESX environment and connect it to a dVSwitch you can't because vCenter will be powered off when you are trying to reconfigure the dVswitch. There's a lot of discussion about this and other similar Catch 22 variations in this blog post by Rich Brambley on VM /ETC and in this post by Jason Boche.

While running vCenter virtualised is supported VMware do not support running vCenter connected to a dVSwitch although you will struggle to find a reference for that. There is a comment on VMware Communities about it and I've been given the same information myself when discussing it with VMware support.

The solution to this is to have a hybrid approach with the Service Console and vCenter (if Virtualised) on a Standard vSwitch. This is what I do when I'm using dVswitches - you retain the single point of management and other benefits of dVswitches for general purpose VM's and avoid the possibility of issues with ESX Service Console networking and vCenter.

2
  • I know this is well over a year old but have any of your comments (Helvick and Chopper3) changed regarding vDS and vCenter on a vDS? I started setting up vDS this weekend and it seems quite solid (VMware 4.1 Update 1).
    – Paul
    Aug 1, 2011 at 11:19
  • I believe this has change, or at least has been clarified so the above answer isn't good advice today. I haven't had the need to test this in anger so others may be able to provide better direct advice. This blog post by Eric Gray over on vCritical explains things quite well - vcritical.com/2011/05/the-secret-of-ephemeral-port-groups - given the presence of at least one ephemeral port group you should be fine with a pure vDS environment.
    – Helvick
    Aug 1, 2011 at 16:36
-1

To follow on from Helvick's excellent answer I would also have to say that from a totally unscientific perspective i have found dvSwitches to be unstable and more trouble than they're currently worth. I'm a huge VMW fan but I'm just not happy with the current version, I'm aware that VMW themselves are working hard to significantly improve the technology and I'm sure I'll use it in the future but for now I've abandoned it in favour of scripted regular-vSwitch creations and changes. Just my 2c.

1
  • I have to agree. I find the general concept of distributed switches appealing but setting them up and working with them is substantially more complex than I think it should be. Scripted installs are a more sustainable approach right now unless you absolutely need features like PVLAN's spanning hosts.
    – Helvick
    Mar 16, 2010 at 20:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.