Day 2 kicks off learning to whiteboard the Value Model: how to work with clients to list needs, outcomes, problems and correlate and prioritize them.
Then we are into determining requirements and using the Requirements Traceability Matrix to organize requirements, risks, issues, constraint, dependencies, exclusion, and assumption. This starts breaking the IT Value Model into smaller parts.
The afternoon covered TOGAF and then DevOps before the daily quiz and breaking into our teams to work on the deliverables for the day.
Every wish there was a 9-day/81-hour course to propel you down the road to being a VMware Architect? Wish no more.
The VMware Center for Advanced Learning has gone live with a course intended to:
Strengthen architectural & solution outcome skills in VMware Sr Consultants, Architects and Partners by establishing a baseline and model to interact with VMware Customers, leading the discovery, design and effectively communicate VMware solutions.
The Advanced Architecture Course is a very comprehensive program covering not just technical content across solutions; but it also includes presentation and business skills, our VMware IT Value Model and Digital Workspace Journey Model, solution design best practices, and internal and industry standard architectural methodologies.
Note that while it seems to have many parallels, it doesn’t actually have anything to do with the VCDX program.
I’m not entirely sure how you go about signing up for it, my company (a VMware partner) received an email in February inviting us to send someone – and one of my co-workers managed to get on one of the betas runs of the class in January, also by invite. You might try @henryvillar who has tweeted about it in the past.
In the run up to class start I received a link to the VMware Wire micro-learning platform which included an AAC prerequisite learning path consisting of 32 hours of training including VMware Hands On Labs and Pluralsight courses covering Agile, TOGAF and ITIL.
(If you are keeping score, that is 113 hours of training so far)
A few days before the class you get a packet to “become familiar with before class starts” that includes a case study (11 pages) and two SoWs (16 and 90 pages).
My class has 31 participants from around the world, grouped in to 6 teams – mostly employees, only a handful of partners – and all men. Your team is important as on the last day you will present a solution you have been working on (as a team) since Day 1.
Class kicks off with a welcome and overview, then you are off and running learning about the IT Value Model and Digital Workspace Journey Model and how important it is to be talking about business needs and outcomes vs product names with client execs.
We then played a game (team vs team) where we chose IT projects to implement for a company based on brief case study and budget numbers. The IT projects were presented with backing information, projected outcomes and cost. The game was great as it made us decide on which projects to execute when and gave quick feedback on the results. I found it very enlightening to see what the class developers wanted us to notice, take into account and focus on.
There’s also a daily quiz, which it turns out counts (along with many other things – tho mostly the team presentation at the end of the class) towards your grade – and you need a 70 at least to “pass” and get the coveted CAL AA badge:
Downside to the class: as a partner you get to see the PS Solution Builder tool which would make my life much easier – but isn’t available to partners.
Way back when I wrote about the “Observed IP Range” information reported for physical NICs in v5 hosts.
I noted among other things that the field seems to be populated by a process that runs at boot time or when you run the “Add Adapter Wizard”.
With 6.x, ESXi seems to either periodically check for Observed Networks, or at least it checks when you refresh the “Physical adapters” tab. This makes it little easier to double-check your network setup.
Note that it tends to post 0.0.0.1-255.255.255.254 if it detects traffic at all and only posts ranges corresponding to broadcast traffic the NICs receive.
non-Broadcast PINGs on NICs 0 and 1: Broadcast Pings:
There’s about a 30 second delays between starting the ping xx.xx.xx.255 -t (which works to populate the fields) and the networks updating.
tl/dr: Enable HA during DLR deployment, don’t specify an HA IP address (if prompted), use a unique logical switch for HA.
Edits: Some info from VMware below. Also, if you are upgrading from 6.3 I would remove the HA IP address first!
I wrote a fewposts last year on the DLR components of NSX – specifically the Control VM that handles dynamic routing partnerships.
There are a few interesting changes to the Control VM for 6.4.0 I wanted to get down on paper cause they can result in a call to support if not handled right.
Enable HA and set an IP
Both of the issues concern the initial config wizard for the DLR. You are prompted on the first page to enable HA.
Make sure you enable HA here! It is very possible to not be able to enable it later w/o a call to support.
Note that whether or not you enable it, on the fourth screen you’ll need to set an HA interface connection.
Also on that fourth page note that you might be able to set an IP address (see my oldposts on what happened with 6.3 when you set it). If you don’t enable HA on the first screen you will be able to set an HA IP. If you enable HA, you might be able to set an IP
If you see an entry for HA IP Do not set an IP address here. This isn’t that bad, as even tho you can add one, it won’t actually retain the IP address you set here.
Look ma! No IP!
The problem comes when you didn’t enable HA during install and go to add it later. Or, disable HA. Because when HA is disabled you can see – and add – an IP address under HA Interface Config:
Compare that to a DLR with HA enabled:
Now if you go and enable HA, you are in a world of hurt
I just deleted it instead of calling support so maybe they have a work around, but best bet is don’t do it!
EDIT: This is news to VMware apparently. Also I would really suggest removing the HA IP (if you configured it) before upgrading to 6.4!
The other issue is the “Connected To:” network for the HA interface. In 6.3 you could easily set the same network for a regular (uplink/internal) interface and the HA interface. and with 6.4 you can easily set them to be the same during the initial install.
But, after deployment, you can’t set the HA interface to one already used by an interface.
But you can set an interface to the one currently used by HA.
Is it a bug? Are you not supposed to used the same network for HA and an interface? If I find out I’ll let you know, but for now I’m creating a unique logical switch just for the control VM HA traffic.
EDIT: Per VMware, set a dedicated network for HA, or use an uplink. Exploiting the interface to set an internal network will cause problems (it will always fail the IP check).
I currently have an open support ticket out on why I lose traffic during a control VM failover – prior to 6.2.5 you would lose pings as the Active control VM would pull all routed from the hosts on its way down, but that was resolved.
Note that I still saw it in 6.3.2 so YMMV.
Now what I see is the Edges changing the internal DLR networks to “Weight 32768, AS Path ?” briefly when the Secondary takes over. I have my BGP timers set to 1/3. I’ll post what support says when I hear from them.
and accepts the initial number (VLAN) as a commandline parameter such as: changeportgroups 123
The CSV file needs: identifier, portgroup name, virtual switch name
If you don’t enter a initial parameter it will remind you and exit.
Entering an initial parameter, the script grabs the line from the CSV where the first value matches your input.
It will then: Pull the PG and VS from vcenter and verify that is what you are looking to work with. Pull the number of VMs on the PG and VS and display and ask which way the move should go (all to VS or all to PG) Migrate the VMs and display the # of VMs on the PG and VS.