• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

Changing your dvPortgroup settings? (need your input!)

Duncan Epping · Aug 2, 2010 ·

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.

Share it:

  • Tweet

Related

Server, Various networking, vds, vSphere

Reader Interactions

Comments

  1. Tim Sheppard says

    2 August, 2010 at 14:21

    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. Rawley Burbridge says

    2 August, 2010 at 14:25

    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. Thomas Nassen says

    2 August, 2010 at 14:32

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

  4. Jason Boche says

    2 August, 2010 at 14:33

    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. Mike Wronski says

    2 August, 2010 at 14:44

    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. David Hill says

    2 August, 2010 at 15:53

    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. Doug Davis says

    2 August, 2010 at 16:11

    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.

  8. AK says

    2 August, 2010 at 17:12

    Yes, I would love to have inheritance back OR a portgroup template of some sort.

  9. RussellCorey says

    2 August, 2010 at 17:46

    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. Duncan Epping says

    2 August, 2010 at 17:57

    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. Mike Brown says

    2 August, 2010 at 18:04

    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. Chris Sauer says

    2 August, 2010 at 18:11

    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. Kevin (Blue Shift) says

    2 August, 2010 at 19:00

    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. Kevin (Blue Shift) says

    2 August, 2010 at 19:04

    …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. Viktor says

    2 August, 2010 at 21:49

    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. Nathan says

    2 August, 2010 at 23:58

    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. Carl Skow says

    3 August, 2010 at 21:43

    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. AFidel says

    3 August, 2010 at 21:50

    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. Peter Van Geem says

    4 August, 2010 at 08:21

    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. Richard Boswell says

    5 August, 2010 at 21:55

    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?

  21. Duncan Epping says

    5 August, 2010 at 23:15

    I gave all this feedback to the vDS guys and they are heavily interested! Thanks everyone,

  22. Claudia says

    14 September, 2010 at 12:13

    Agreed – please bring back vSwitch inheritance.

  23. cmegroz says

    13 April, 2013 at 10:51

    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. Johann STander says

    27 August, 2013 at 23:54

    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

    • Dave says

      4 September, 2013 at 22:39

      Hello, any update to this thread?I also have the same issue in a VCD environment.

      • Johann says

        9 September, 2013 at 23:43

        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.

      • Michael R. says

        30 June, 2014 at 17:31

        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.

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007) and the author of the "vSAN Deep Dive" and the “vSphere Clustering Technical Deep Dive” series.

Upcoming Events

25-Feb-21 | Swiss VMUG – Roadshow
04-Mar-21 | Polish VMUG – Roadshow
09-Mar-21 | Austria VMUG – Roadshow
16-Mar-21 | VMUG Turkey – Roadshow
18-Mar-21 | St Louis Usercon Keynote
26-Mar-21 | Hungary VMUG – Roadshow
08-Apr-21 | VMUG France – Roadshow

Recommended reads

Sponsors

Want to support us? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2021 · Log in