Originally posted by: The_Doctor

FYI, I find the logistics of creating a new virtual switch very un-intuitive.

Scenario:

• HMC @  v8.8.6.0
• new Power8 frame @  FW860.12 ,  started in Standby mode
• no VIO Servers, no LPARs, no partitions of any kind running yet.  It's a fresh brand new machine.
• our network plan calls for 2 Virtual Switches.... the default ETHERNET0 + one more switch 

Attempts to create the 2nd Virtual Switch were severely hampered.  Seems the Enhanced GUI wants me to define a network when adding a new switch.  But I don't have a network yet plus I don't have any VIO Server(s) yet.

 

Regardless, I proceed anyway...... attempt to create a totally bogus network with my new 2nd switch..... and get this --> 

 

 

Of course I'm not in Operating state, I'm in Standby state.

 

I then abort the Enhanced GUI process and go to the HMC command line.  I then attempt to create my 2nd switch from the command line only to find the 2nd switch is now present ..... despite the above error message.

 

Bottom line..... I think I should be able to create a 2nd or 3rd virtual switch.... without requiring:

• the frame to be in Operating state
• operational VIO Server(s)
• defining a bogus network

IMHO, the Classic GUI had the sequence right.

 

Originally posted by: sashok

Thanks for sharing your opinion!

 

The enhanced UI introduces a new PowerVM management model where rather than thinking in terms of primitives like creating a vswitch, creating a VIOS and activating it, creating a partition, creating veth adapters and trunk adapters, creating an SEA, etc., you think in terms of the overall provisioning scenario - putting a partition on a virtual network.

 

The idea is to simplify the existing scenario of assembling PowerVM infrastructure brick by brick.  For new users to PowerVM this should be more intuitive.  However, for existing users who are used to dealing with primitives, it will take some getting used to.  The hope is that by migrating to this new model, it saves time in the long run from multiple tedious tasks.

 

If you have a brand new system, have you tried system templates?

Originally posted by: ssrjazz

I gotta say this response worries me greatly.  I'm all for being able to manage more VIOS tasks via the HMC, but the idea that you "don't have to worry about things like VIOS SEA and trunking adapters, etc" is leading users to a place where, if it breaks, they don't know how or what is broken and/or how to fix it.

 

You still need these things, so how will they be managed/maintained and provisioned with this 'new model'?  You still have to understand the underlying physical structure to provision things in a way that makes sense for that environment.  Hiding that away is going to hinder how well Power servers can be integrated into a legacy customer environment......or a new one, for that matter.  Each environment is different.  

Originally posted by: PeHo

I completely agree to that ! For me running HMC as a black box without understanding the underlying concepts and procedurs can't be the right way .... especially when something goes wrong and you have to do kind of analysis and troubleshooting!

Originally posted by: Anjil

Thanks for sharing your observations on the HMC's newer Virtual Network Management model.
Regarding, creation of virtual network when system is in standby state, we should be allowing to create a network in this state and thanks for bringing up this observation, we are looking into the issue.

Please refer the blog we have put together at https://www.linkedin.com/groups/8403988/8403988-6265011587262799872 which introduces the newer network model and provides the mapping of the newer model with existing components.  While it simplifies the user's experience in setting up network and connecting a VM to the network, this model also provides the options to set the detailed network attributes (for advanced configurations)  of a virtual adapter through 'Adapter View' wherever applicable (On Client Network Adapters and Trunk adapters) .

This model avoids the need for creating a Virtual Switch separately and is provided as part of network creation. Post creation of a network user can still edit the switch attributes. The Virtual Switch gets deleted when last virtual network associated with the switch is marked for deletion (the non default VSwitch).  All that user need to take care of are configuring a network in the system and adding/removing the VMs to that network.

Please note that the configuration created on the VIOS and Client Partitions in the background is still the same (Trunk Adapters, SEAs and Client Network Adapters etc). User should still be able to view and modify the details at NetworkBridge (SEA) and LoadGroup (Trunk Adapter pair) level.

The newer model abstracts the complexity of this configuration  and avoids manual errors involved while configuring them individually. Please refer the blog and provide your thoughts on any specific configuration that you feel should be included further in this newer model.

Originally posted by: Anjil

Adding further to my previous post, we have identified some of the error scenarios during which we might end up having the stale devices like TrunkAdapters. We have improved on these scenarios, and added roll-back of the configuration to the possible extent during failures. Also working towards providing interfaces to cleanup any of such devices which are not manageable through Enhanced UI currently.

Originally posted by: FuzzySCSI

Sorry to be late to the party - I have JUST found out yesterday the Classic UI was going to be withdrawn altogether in favour of the Enhanced UI as of R8 V8.7.0 of the HMC.

Upon hearing the news, I had to go back in my notes and reopen a discussion I had with a colleague - either late last year, or earlier this year - whereupon we "discovered" the presence on the enhanced UI by accident - tried to use it for a while, but quickly returned to the Classic - because the new UI was just not practical, and we could not use it intuitively to perform tasks we've always been accustomed to perform on the Classic.

 

We are currently at R8 V8.6.0 on our main HMC.

 

The key stumbling clock we encountered on the Enhanced UI, is we could not add a virtual switch.  Going back to the environment now, even just to peek and refresh our recollection of the issue, I stumbled on yet another concerning situation - The Enhanced UI throws an error I could not even begin to imagine how I could address,  Here are a couple of screen shots to illustrate.

The first, I've opened the HMC in Classic UI mode, and requested to display the Virtual Switches from my 2 power server.

 

 

Then, I repeat the task, and request the same information using the HMC in Enhanced UI mode, and got an error on one of the servers:

 

 

I'm sorry - but I have a serious problem with being forced to switch to a new "Enhanced UI" that can't perform the same task the Classic does without errors.

 

You want intuitive?  The Enhanced UI "Action" button above was disabled. In my humble opinion, it should have been active, and provide me with the mean to "create a virtual switch" if I so wished.

 

I am a technical consultant employed by an IBM Business Partner.  We have years of experience with the HMC and the tasks we need to perform in deploying VIOS and LPARs, and have several clients depending on the HMC to manage their systems. Even the look and feel of the Power Nodes management in a PureFlex chassis using an FSM matched the HMC's Classic operation making THAT transition "intuitive" for everyone!  Customer environments have long been "established", and "stabilized", and are - for the most part - operating in "PRODUCTION" mode.  Those customers are not going to want to use this "Enhanced UI" that is clearly not prime-time ready and has the potential to disrupt a production environment as their administrators attempt to get up to speed with the new way of doing things.

 

Even if the future is the Enhanced UI, would it be so wrong to keep the Classic interface available a while longer, thereby giving a chance to get the Enhance UI better fine tuned and polished?  Better yet, keep the Classic UI available as a separate product altogether.  My perception is that, even though the Enhance UI may have been made available, it's been - for the most part - ignored.  The Classic UI is a strong proven interface.

 

In my opinion, there is a certain level of product legacy support that we should keep available to the POWER# Server client base, and I consider the Classic UI for the HMC to be a key component of this support for my client base.  Imposing this change - IBM are not doing any favors to their client base - that is for sure.

 

Serge

 

 

 

Originally posted by: sashok

Classic UI withdrawal was announced when 8.6 was released last year.  We also blogged about this in October at https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/What%27s%20new%20in%20HMC%20V8%20R8.6.0.

 

The classic UI and enhanced UI have both been supported for two years now.  And the 8.6 release will continue to be supported until 4Q next year, so there's plenty of time to learn the enhanced UI.

 

Have you seen our blog on virtual network management at https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/Virtual%20Network%20Management%20with%20HMC%20Enhanced%20UI?  It maps classic UI concepts to the new enhanced UI model, like explaining how a vswitch is part of a virtual network.  You no longer create a vswitch, veth, trunk adapter, log into VIOS and create SEA pairs and control channels, etc.  You just create a virtual network and let HMC handle the underlying individual operations.

 

Nigel has done a very nice overview as well -> https://youtu.be/RReXXDp4gxc

 

The error you're receiving is from the VIOS.  The enhanced UI treats VIOS as part of the platform to minimize the context shifts to its CLI.  As such, it makes many more API requests to VIOS than classic UI.  Unfortunately in this case there seems to be some problem with the VIOS.

Originally posted by: FuzzySCSI

Thanks for your reply Sashok.

 

I appreciate the links and resources you posted in your response.

 

Where you lost me is when you said: "let HMC handle the underlying individual operations.".  Automation (which is what I relate your " let HMC handle the underlying individual operations." to) is all fine and dandy until things don't work as expected and - as someone else already pointed out - troubleshooting needs to take place.  Also, I understand how the Enhanced UI may make "more API requests to VIOS than classic UI", as you indicated, but the point I'm trying to make is more about how the Enhanced UI handles the error condition - or rather doesn't, at least not very well.  As you said, in my case "there seems to be some problem with [one of] the VIOS".  However, the error posting does nothing to help guide me in the troubleshooting to address the issue.  My experience with IBM software is that, as bad as a situation may get, there usually is an error code/label associated with the error, and that can go a long way towards obtaining the right support for the issue. [Is the problem really on the part of the VIO, or the HMC console software?].  Consider for a moment that my VIO has been in operation, without issue, for some time.  In light of all these threads about the Enhanced UI's performance, and add to that my experience in IBM's release of one new UI after another on a few other software I've had experiences with, you might appreciate how it is that I can't bring myself to trust the new Enhanced UI and finding it hard to justify spending my time to go through the process of troubleshooting this particular condition.  What's worst, is that I haven't done anything yet - I only attempted to "look" at what my current virtual switch configuration is when I got the error.

 

Regardless how I got here, I am now concerned that  I may have a VIO problem, and it is nagging at me.  This condition so reminds me of when a system board firmware update rendered a customer's POWER node (in a PureFlex chassis) inoperable unless we downgraded the firmware, or replaced the CPU.  In that case, as it turned out, it was determined we actually had been running with a faulty CPU all along.  It was the updated resources test routines of the system board's new firmware code that identified the internal CPU fault and prevented any further operations to take place, something the older firmware code level hadn't tested for.  It took a few days to resolve, the swap of system boards, and other peripherals since the error condition never made it to screen (it just perpetually rebooted).

 

At the root of it all, the way I see it is: a UI is a "User Interface".  A "Classic UI" tends to infer a level of legacy or history for providing a certain level of access to procedures/functionalities against [in this case] managed systems.  An "Enhanced UI", at least to me, infers that some improvements on a "UI" have been added - either by way of presenting available relevant information to the user in a better more cohesive way [which can be related to as a new dashboard], or perhaps by way of encapsulating a set of tasks in a way so as to simplify or automate these thereby effectively [hopefully] reducing the possibilities for human errors as much as possible.  We can both agree the Enhanced UI does both here.  Where the line blurs is on the keyword "added".  Nowhere does "Enhanced UI" ever infer legacy functionalities would be withdrawn or be replaced by more "convenient" encapsulated tasks.  Leave the basic functionalities accessible.  If I want to "create a vswitch, veth, trunk adapter, log into VIOS and create SEA pairs and control channels, etc", let me have that choice from within the "Enhanced UI".

 

Every heard of the Harmony TV remote? It gives me "Classic" operation of my amplifier, cable/set-top box/receivers, TV, DVD player, CD player, and a panoply of other devices individually, and offers me "Enhanced" functionalities by providing me with a one button task for turning on just the devices I need, placing each of them in just the right mode, for when I want to watch TV - as opposed to listening to music, or playing a PlayStation game, etc.  There are times these "one button" solutions don't work exactly as planned for whatever reason.  I should still be, and actually am, able to control an individual device to rectify the condition without having to dig for my original/old device remotes - and the Harmony remote's "Classic" level support does that.

 

I apologize if I seem to have gone off track a bit (or a lot).  This change is going against my principles in a big way, and I guess you could say: this was my "straw that broke the camel's back".  I felt I needed to speak-up on this matter.

 

Kind Regards,

Serge