Yellow Bricks

by Duncan Epping

Changing your dvPortgroup settings? (need your input!)

I am just wondering if I am the only one who doesn’t understand this. I had a discussion with our vDS team around changing the dvPortgroup settings. This can only been done after the dvPortgroup has been created. On top of that it gets created with standard values of which some don’t really follow my general best practices. (For instance Forged Transmits is set to Accept by default instead of Reject.)

With a regular vSwitch you could just set all your preferences on the vSwitch. The Portgroups that you would create would inherit the properties of the vSwitch. Of course when needed you could always override these properties on a per Portgroup level. However with a dvSwitch this isn’t possible as you cannot set these properties on the dvSwitch level. A dvPortgroup however is created with default settings which you can’t change during the creation.

Apparently this decision has been made after many customer complained about the complexity of the vSwitch / Portgroup inheritance concept. I have never found this a problem, or even complex to be honest and I was wondering what you think about this?

Do you prefer the current method or would you for instance like to have the option to change the defaults? I think having a “default dvPortgroup template” would be a nice enhancement. Please leave a comment and I will, if needed, contact our Product Manager to discuss this and will do my best to get it on the roadmap.

Reader Interactions

Comments

  1. I also thought it was strange to change from the inheritance of vSS too. Never had a problem with the configuration nor explaining it to the students I have taught. The vDS way seems overly complex and loads of students seem to have difficulty grasping the concept.

  2. We have ran into this problem with Lab Manager installation. Our normal standard is to use IP Hash load balancing, however we have found that when new configurations are deployed the vDS port group for that configuration defaults to Virtual Port ID. I would prefer for inheritance to still work.

  3. Yeah, same here. Bring back the inheritance….
    The idea of dvPortgroup templates is a good one,
    would come in handy at times.

  4. I was going through the “Mastering” book last night and saw my own notes about settings being defined at the vDS portgroup level and not at the global vDS level which differs from the virtual (standard) switch. The same goes for the actual number of ports themselves, but to me this makes more sense for the vDS.

    I thought it was a bit odd for VMware to change this behavior but figured there must be a technical, security, or political reason behind it. I view the settings at the vSwitch level as a “template” which would typically cascade down to the portgroup level. I can only think of a few specific reasons where the portgroup configurations would differ from the vSwitch configurations. Right now, I can’t say that it bothers me. I don’t see it as a loss in flexibility. Maybe a little more administrative burden because now each portgroup on the switch needs to be configured to your standards instead of inheriting said standards from the switch level. I don’t use the vDS other than in the lab.

  5. I dont think regular vSwitch complexity lead to the dvSwitch as from a configuration/complexity perspective dvSwitch is far more complex.

    My preference is always choice so the ability to enable inheritance would be ideal. Until then, we use profiles to manage the configurations.

  6. I must agree that not being able to set the defaults for the vDS port group adds complexity and also provides a management headache when using Lab Manager, or any other automation method.

    I for one would be very happy to see a new feature allowing you to set the defaults on the vDS port groups. The main issue for me is the default setting of only having one active uplink. This is a real headache when the port groups are created via the API’s.

  7. Inheritence has never been an issue for me – in fact, because of the way we use portgroups in our environment it would be a real pain without it! We won’t be using vDS anyway as we don’t have licensing for it, but I think you should at least be able to enable/disable inheritance or have a template you can use for dvPortGroups.

  9. Hrmm I see the DV Portgroups as your “root” management object and the individual switchports inherit from that.

    From a labor standpoint its not too different since you only really have to define the portgroup globally.

    I think the catch here is from a vSphere admin perspective the vSwitch—>portgroup model makes more sense; where from a network administrator’s perspective the portgroup—>switchport model makes more sense.

    Couldn’t you define a default DV portgroup via a host profile anyway?

  10. Yes but that is reactive instead of pro-active isn’t it?

    Lets assume the following: you have standard policy where you set LoadBalancing to “Route based on physical NIC” and “MAC Changed to Reject”. In this case very dvportgroup you create manually needs to be changed after creation. In an enterprise it is not uncommon to have 30 – 50 dvportgroups. If you can set those common policies on a level higher or have a portgroup template the issue is solved without needing to resort to scripting. (which not all people like to do…)

  11. I’m with you 100%, I’d much rather set my default policy high and let it inherit down and override anything that needed to be.

  12. I agree with you. Because of compliance dealing with network segmentation, I have a few portgroups. Managing these portgroups at HQ, DR, and various world wide locations can be annoying and settings can be easily missed.

  13. An ability to create and enforce dvPortgroup templates would be ideal.

    One of the benefits of the dvSwitch (as well as Host Profiles)is to reduce errors and enforce consistency across hosts. This seems to be a step away from that idea (an unintended consequence?) in the name of reducing perceptions of complexity for some customers in order to gain broader market acceptance.

    In the short term I personally would perfer that the dvPortgroup settings don’t get trampled by inheritance as it can create unanticpiated changes for customers — and if they are aware — require siginficant remediation efforts.

    It’s very easy for someone to implement a dvSwitch and be blissfully unaware that some of the portgroup settings are being changed/reset.

    In the long term having a template that can propogate and enforce the desired settings with consistency would be ideal.

  14. …and if the template function takes too long to develop…a quick solution would be a toggle (hidden somewhat) where advanced admins can at least turn on inheritance.

  15. I would love the idea of a portgroup template, or as an alternative a default setting that the de portgroup is not active at all. Currently if you create a new port group, ALL connected adapters to the DVS are marked active in this new portgroup…not a good thing I think.

  16. Personally never had an issue with the vSwitch Port group inheritance concept.

    From experience speaking to various people at VMUG’s, where you say the decision was made after “many customer complained” is VMware is no longer at the big end of town but has well and truly entered the small business realm and networking concepts are still to be comprehended by those administering these systems, nothing against this it just time and experience.

    I am currently running a number of DVS switches across clusters and linked sites, to set the defaults at the switch level would be really cool and I was surprised this could not be done at this level, it would make logical sense to do so as you would on a normal switch and then override these policies at the port group or port level.

    Just my 2 cents.

  17. I’m with you 100% on this, the parent (dvSwitch) should define the settings to the children (dvPortGroup), unless they are overridden with discrete changes at the dvPortGroup level.

  18. Nathan how many SMB’s are buying Enterprise Plus? I would say not too many, so if you’re big enough to need DVS you probably are also big enough that templating and repeatable process far outweighs a bit of additional complexity.

  19. I always wondered what the actual purpose & use is of the vDS Uplink Group object.
    I initially thought that this object was the place where we could set these portgroup preferences so it at least would have some purpose, as now you see the settings but you cannot actually configure them, except for the traffic shaping.
    So why is this object needed anyway ?

    A future change could be to group portgroups with same properties under a new “template” object as a child object of the vDS & maybe the ability of creating multiple of these “template” objects to group portgroups with same policies.
    Also on the “template” object you should be able to define if the policies could be overridden on dvPortgroup object or not….

    Example:
    You could have a “template” object that reject the 3 security settings & that prevents these setting to be overridden on portgroup level.
    You could have another “template” object that only allows the promiscuous security setting and that allows policies to be overridden for all portgroups underneath this uplink object. Underneath the latter uplink object you could create all the special portgroups you might need like for MS NLB, sniffing etc…

  20. I sat in on a Host Profile discussion with VMware’s Product Managers for Host Profiles/vCenter in March and asked for this very thing, a way to emulate a Host Profile for a vDS. Hopefully something will come of it?

  23. Hi,

    is that this point is still valid?

    we have a problem with the DVS and IP Hash policy.

    In a vCloud Director infrastructre, connected to the Cisco Nexus, it is imperative to have all ports in LACP, with the Cisco vPC. This to prevent the flows passing through the interlink of switches.

    Unfortunately, as it has no default policy on the DVs, at the automatic creation of a VM Port Group by vCloud Director, we have packet loss due to the original Port ID policy .

    a manual action is required and IaaS customers should expect the support team does.

    Is it possible to ask the development team corrected this?

    thank you

  24. Hi Duncan,
    I know this is an old thread but currently experience this exact same situation with our Vcloud director 5.1 and trying to figure out if there is yet a solution to this problem.
    As users specify we make use of IP hash load balancing with 2 active uplinks and since port groups are not created with my specifications it causes the network to break for host spanning and external networks within vAPPS.
    Cheers
    Johann

      • Hi Dave,
        I was able to find a workaround for this problem removing all the uplinks from the vDS which is associated to the vCDNI, and setup new uplinks with physical ports on which I assigned the same VLAN ID as that of the vCDNI network.
        I dont really promote my site and really just for me to put information down instead of my OneNote where everything current reside: http://virtualrealization.blogspot.com/

        Hope this helps.

      • Same here .. I have found some powershell scripts online which supposed to change the default settings of the vDS but this isn’t a supported workaround it seems so we need to steer clear from that. I have been in contact with VMware Support and their workaround is using either VXLAN (which we can’t) or use Portgroup Backed (which we can’t)… So our only workaround was to remove the channel groups and use a different teaming policy instead.