dvSwitch Migration .. Ok, but why this way?

[HenrikElm]

Please look at the enclosed JPG from a VMWare presentation.

Originally you have two switches. Now, at step 3 you merge those two switches into one dvSwitch, using the settings on the portgroup to enable or disable the correct uplinks (I guess?). Fine.

1) Why not stick to still using two (dv)switches even after bullet 3? What is the actual advantage you get by merging them into one dvSwitch?

2) If it was always a good idea to use a single switch,in all honesty why did we ever create more than one switch? Could we not always have survived using a single switch that we connected all NICs to and used the portgroup settings to steer the portgroups to the correct NICs?

I will get my head around dvSwitches, bu I need to get the architecture straight first..

/Henrik

[HenrikElm]

Aha!

The enclosed graphic explains my question number 2). You should create a new switch when talking to another broadcast domain. Ok.

But..? Isn't this true anymore with dvSwitches and its uplinks? Correct or not?

Bullet 3 in the first slide suggest not?. Someone please clarify before I go mad..

/Henrik

[Optic_Nerve]

Hi Henrik,

I tend to agree with you - I do not see anything new in vNDSs that would suggest you can consolidate multiple vNSSs into a single vNDS.

As you stated - if it was always a good idea to use a single switch we could have used port groups to steer VMs to specific uplinks even with vNSSs. I cannot see why you would choose to use this method any more strongly with vNDSs.

I do have one theory. When you create a vNDS, VMware automatically creats an "uplink group". This group appears in the same list as your port groups appear but with a different icon (looks like a network card). This uplink group cannot be deleted.

I have been playing with the Cisco Nexus 1000V vNDS and you are able to create multiple uplink groups on a single vNDS. Perhaps the diagrams from VMware are alluding to the fact that you can have multiple uplink groups (which map to different pnics), and then each port group is associated with an uplink group...?

If there is a way to create more than one uplink group in a VMware vNDS then I haven't found it - but it can definitely be done with the Nexus 1000V (which means the API itself obviously supports it).

Anyway it's just a theory.

Cheers,

David

[HenrikElm]

Hi David. I very much appreciate your reply.

Ok, at least we are two that is wondering/sceptical to the graphic from the slide. Now I think I get the architecture behind a vDS. I just created two instead of one and that (of course) works good as well. Actually it is very easy to migrate the VMKernel pgroups from one vDS to another with no downtime.

What would actually be the difference between creating a brand new uplink group and connecting dvPortgroups to a set of NICs in the normal way? Ah.. I guess you gain the possibility to set different global properties on the group, right?

/Henrik

[admin]

You need to create multiple vDSes one for each broadcast domain. We recommend using vlans to separate out the traffic where possible at which point this consolidation step becomes possible.

[HenrikElm]

Ok. Even when you hard-connect portgroups to different uplink groups? Is it really a dvSwitch to needs to be in a b-domain or a set of uplink groups used together?

/Henrik

[Optic_Nerve]

You need to create multiple vDSes one for each broadcast domain. We recommend using vlans to separate out the traffic where possible at which point this consolidation step becomes possible.

...which is exactly the same as it was with a vNSS. So there is no "consolidation story" at all when comparing vNSSs with vNDSs (which is what I already thought was the case).

The slide going around in the VMware presentation about vNDSs is very misleading - it definitely gives the impression that there is a consolidation step when migrating from vNSSs to vNDSs. While you can consolidate using VLANs, you could do this with vNSSs as well.

Cheers,

David

[howie]

> The slide going around in the VMware presentation about vNDSs is very

misleading - it definitely gives the impression that there is a

consolidation step when migrating from vNSSs to vNDSs. While you can

consolidate using VLANs, you could do this with vNSSs as well.

The higher consolidation comes when you have lots of hosts, vDS gives you much easier way to manage. vDS has a number of additional features that vSS does not have such as PVLAN. Does it make sense or you expected something else?

[Optic_Nerve]

Hi howie,

No - I was not expecting anything more than this. The slide is misleading because it shows a host with two vNSSs being migrated to a single vNDS. In reality, if you needed two vNSSs previously then you need two vNDSs now.

This was really just a discussion to see if we were missing something obvious. It was triggered purely by that slide. The slide shows two vNSSs on a host being reduced to one vNDS. I do not believe there is anything new in vNDSs that would achieve this.

Of course there are lots of other great things about vNDSs and I love them already. There is consolidation in the sense that you only have to configure it once - but that is not the same as consolidating two different switches down to one. We were just wondering if we were missing something fundamentally different about vNDSs which allows for less of them per-host.

Cheers,

David

[howie]

It is true that instead of manging two vSS on two hosts, you manage one vDS on one cluster.

Btw, this is all software, whether one vswitch or two vswitch, other than the management hassle (that hopefully vDS is addressing already), do you really care 1 vs. 2 vDS? Also in theory you can consolidate everything onto on vSwitch and use VLAN/PVLAN to do the isolation.

[Optic_Nerve · Accepted solution]

Hi howie,

I think you are missing the point.

The slide specifically shows two vNSSs (on a single host) being consolidated into a single vNDS (which implies that there is something inherently new in vNDSs that allows for this to happen). This is not the case, there is nothing new in vNDSs that would reduce the number of vSwitches per host. That was our only issue. This has nothing to do with managing a single vNDS for multiple hosts (which is obviously a huge new feature!).

This was nothing more than our confusion that the slide made us think we must be missing something new in vNDSs and we wanted to find out if that was the case. Nobody is knocking vNDS switches. No, I do not care that I have 1 or 2 vNDSs at all. I merely wanted to make sure I wasn't missing something and I'm not. The slide is simply misleading. In reality, if you have already consolidated your vNSSs using VLANs (which we have always been able to do), then migrating from vNSSs to vNDSs is going to result in a 1-to-1 mapping. This is perfectly fine - again, the entire point of this thread was to make sure we weren't missing something.

Yes, you could consolidate everything to a single vNDS and use VLAN to do the isolation but we could always do that with vNSSs as well. Once again, the point was merely to confirm whether or not there is something new in vNDSs that allows for fewer of them to be used. There isn't.

It's all good......

Cheers,

David

[howie]

> Yes, you could consolidate everything to a single vNDS and use VLAN to do the isolation but we could always do that with vNSSs as well. Once again, the point was merely to confirm whether or not there is something new in vNDSs that allows for fewer of them to be used. There isn't.

Yes, we are on the same page.

To make my comment future-proof, we are obviously looking at evolving vDS feature set and I'm not here to rule out the very "misleading" piece you were looking for. We can discuss further privately if you have NDA with us.

[HenrikElm]

Yes. David understood my question/concern exactly right. I am happy that we have worked through this issue. I now conclude that a dvSwitch is more or less a centralized switch (good thing!) with some additional functionality, but does not change networking design in itself. That part should be done as earlier, and the consolidation shown in the slide as "this is how you upgrade to a dvSwitch" could (or even should?) also have omitted that step and kept two switches afterwards.

Thank you all for clarifying this matter and hopefully others that read this thread also understand a dvSwitch better as well after reading this.

/Henrik