HPE OneView Reviews

The ability to administer multiple servers simultaneously, upgrade firmware, and add the client support pack.

The main benefits are a single pane of glass, usability between the servers, storage, and network.

I would love the ability to either import a range of IPs for the ILO, or be able to do a scan. If they could improve the IP range, that would be great.

Stability seems fine. I haven't had any down time.

Scalability seems to be pretty good. It's a little small for what we have right now for a number of servers, but I think it will grow.

I haven't needed technical support.

We did not use a different solution. I try to stick with a vendor with the hardware. When looking for a vendor, specifically for this product, it has to do with our activity and our hardware so we are able integrate our APIs with the system.

I was involved in the initial setup and it was very straightforward.

I would recommend doing a beta test.

Profile templates: The ability to generate the profiles and lay them down so the servers are built consistently. I would say that's probably the biggest piece of it.

To be able to rapidly roll-out a lot of servers consistently and quickly, without having to go in and tweak each thing individually. After we get the template built, we can just apply it and push it down

It's a nice product. It's a little slow sometimes. Overall, I think it does what it's supposed to do. I think that as they evolve it, it'll get quicker.

Stability's been fairly good on OneView, the appliance. In terms of Synergy Composer, which is a OneView central derivative, it is a little slow being on that bare, metal hardware. It would be nice to have one product, OneView, that could manage both Synergy and legacy devices without having two separate products. I understand that's what the dashboard is all about, but it still would be nice to have less components.

We bought Synergy because we were doing a Greenfield and we knew that the writing was on the wall as far as what the future was going to be in terms of Synergy versus C-1000. The choice was to not invest in the older technology, but rather to invest in the newer technology to future-proof ourselves. 

That dictated that we needed a solution. As to why did we chose one or the other, that was basically future proofing. 

It is a little scary to be the "data customer". We're one of the first 50 customers right now to purchase it. Composer is one unit in Synergy, but it's a physical appliance. We also have to other appliances to manage all the old legacy stuff: C-7000, 580s, 380s, anything else you'd want. So we have both of those. It wasn't a choice of one or the other. You have to have this for this and you have to have that for that. 

That single band of class that is kind of the manager of the managers. It really saves a lot of time. One of the main reasons we didn't use OneView sooner with our older environment was one of the initial caveats. Once you brought a box, or you brought a C-7000 chassis into the OneView management purview, it basically took over and did a whole bunch of stuff. You have to plan it out because it took over and you would have to reconfigure things.

Instead of just taking it in, and leaving things in a view-only mode, so I still can see it. Maybe at least I could view it in a single pane glass so I could see where things are at. That was kind of why that supposedly had been fixed. You can now bring things in without outages, but I don't trust it. I will delay the evacuation of a chassis to the time when we bring that in.

The counterpart who I work with did the majority of the actual hands-on setup. He worked with HPE to get them committed. 

On the Synergy side, for Composer, (OneView composer), he also did the deployment for the virtual appliance that we rolled out, our C-7000. For some of the view, we only brought some of our rack mount servers into view-only mode. I use it, but I didn't implement it.

I think the implementation was pretty straightforward from what I could gather. It didn't look too complicated, at least on the appliance side. I've been told that you can create profiles for hardware that you don't have. 

My biggest gripe is that a profile is tethered to a particular hardware type. I would like to be able to take a profile, of more generic nature, and apply it to different types of blades without having to build another profile for that blade type. I would like some inter-operability there, without having to have multiple templates. Other than that, it's been fairly stable. 

I think there are some configuration things you can do in Virtual Connect that can harm you from an availability standpoint. OneView still allows you to do that, which I don't think it should. Those are just my thoughts, as far as a criss-cross between virtual connects, where you can actually create an outage for yourself for updates. But other than that, it has met our needs. I think the biggest things for me are the profiles that I can flip between different hardware types.

As the guy that does the work and not the guy that handles the money, I am interested in whatever makes my job easier. Simple is always better. If it's a simple, straightforward solution, that is always the best solution for me as an engineer. 

For the people that handle the purse strings, I guess money is a greater concern. As far as the technology goes, anything that makes my life easier and I don't get calls in the middle of the night, that's what matters to me. That should matter to the business as well. Obviously, if I'm not getting calls, then things are up. If it's simple, it's better for everybody, in terms of the roll-out times, troubleshooting, and fewer pieces to break.

I would say the only competitor is probably Cisco solution. Their competitive or comparable product, in the OneView space, is kind of the manager of managers, is UCS Central. It has been out for some time. I feel, in some ways, OneView's doing a little catch-up to them. That's just my opinion, as I've used that in the past. 

My company is a very HPE heavy company. They have been way before I came to work here. I think in many respects, you kind of go with what you know and what you are comfortable with. That's what they've always been used to, so they have a good relationship and they've continued on that path.

I think it's good to know that if they already use HPE products, it may not be time to start analyzing whether or not to use competitive products. I think competitively, there are probably some advantages to one of the other possibilities. However, I don't think it is necessarily a good idea to throw out what you have now in order to switch.

It provides easy administration.

It minimizes our administration for the market.

I would like to see, probably a little bit tighter Type B integration.

The product is really stable.

It is very scalable.

The technical support team is very responsive.

Actually, it was just that, at that time, we decided to invest in this solution. We were still using the HPE ConvergedSystem.

The setup was very complex, but it wasn't always complex. We had some issues at the micro-level, but they resolved all of that.

We were still using the HPE equipment before the ConvergedSystem.

The stability and support are important factors while selecting a vendor.

I would actually look at the support model for HPE in the newer versions.

Its simplicity is the most valuable feature.

It is easier to manage and has one central location.

For a code upgrade, there should be more stability in the code.

To be honest, we've been having some issues with the stability of the product. We're working with the support to get it more stabilized. We did a code upgrade and the whole thing just fell. Our guys back home are still working on fixing it.

We're still in the beginning phases of using it, so I don't know how it's going to scale out or not.

The technical support team is okay. They didn't fix the problem at the first time they connected with us, so we're not too impressed, at the moment with them.

This tool was recommended to us by our partners. We then had it included with the service that we bought and implemented it.

Reliability is the most important criteria while selecting a vendor.

Try a PLC first.

The visibility of the status of the IT infrastructure.

The improvement was basically to be more efficient and have a lot of productivity. We are more developed to creation rather than just solving problems.

The possibility to do more analytics regarding the status of the assets.

To improve our political mission process and workflow.

It is very stable.

We can grow according to the needs of the IT and OT requirements.

We needed some support from HPE in Mexico, I think. I would give them a rating of 9/10.

I was not involved in the setup. The management was involved in the setup.

We checked with IBM a little bit. We went back to HPE because most of our infrastructure is HPE service and also cloud solution

It's quite important to improve IT operations to reduce the time IT people devote to solve problems. Instead, we can create valuable position innovation ideas to improve the business.

I have heard of what the benefits are supposed to be and we're trying to get to that state, but we're just not there yet.

Before OneView, for us, we were trying to manage all the separate enclosures with the Virtual Connect tools and it was cumbersome. To be honest, it was never done because it was so cumbersome. So, hopefully, OneView is going to resolve that issue, however, it just hasn't yet for us.

We are just now starting to bring it up, it has taken us around eight weeks and we haven't still been successful to bring it up. We have hardware or blades that can't see themselves within the enclosure of OneView managing them.

Hopefully, it's just going to be more stable and we can get functional, i.e., get up and running quicker than what we've seen.

The product is not stable.

We have used technical support, I would give them a 5/10 rating.

We would like to see quicker times for a resolution. It seems like when you get on the call, the technical support you have is this one level tier, who ask for a bunch of data logs and then, you get to the other technical guys who ask for the same information. You go on with this continual loop for weeks on end.

Previously, we were not using any other solution; it was just managing the virtual connecting individually. We really didn't have a choice in selecting a particular product as such, that was just the direction in which the organization was going.

We looked at CISCO's DCS platform, but we're an HPE shop and there was no major direction to change.

The hardware's reliability and manageability are important criteria while selecting a vendor.

Just make sure you put it through the paces. Again, I don't know what failed in our deployment. I've talked to some of the escalation engineers at the conference and hopefully, they're going to come back and resolve the issue. But, our IT is lean. We don't have time to be beta testers for new products, we need a product that's going to be stable out of the get-go.

The centralized management of the HPE Virtual Connect (VC) is the most valuable feature.

Just having a centralized view, instead of having to go to each chassis for managing Virtual Connect is very helpful; I got it all in one place.

It tends to detect flood conditions on a lot of the networks. I'll have blades that are suddenly offline because it detected a flood condition on that particular NIC. I've called support on that and they're like, "Yeah, we have detected a flood condition, it is a loop." However, I tell them, "We don't have a loop." So, you reset it and reboot the blade; the ESX comes back up and away you go. That has happened to me three or four times now. So, hopefully, we can figure out what's causing this at some point in time.

It has been stable, I haven't had any problems with it at all.

We have six HPE c7000 chassis, across two data centers and everything is good. We have a single OneView product in each location.

I have used technical support. It has been probably a year, but I have used them. They are excellent.

Previously, we were just managing the blades directly through the HPE Onboard Administrator (OA) and Virtual Connect (VC). We were building up brand new data centers, with brand new equipment and we had the choice of doing it the old way, or using OneView; we could just have two places to see it, i.e., one on each data center. So, we decided to combine it, this was a suggestion by one of the partners.

Stability and support are the most important criteria while looking for a vendor.

The setup was straightforward; it was pretty easy. It's a pretty simple setup; you just install your server. It's a virtual appliance and you throw it on there, start it up, add your chassis and away you go.

If you are experienced with OA and Virtual Connect, that it's a completely different animal when you're in OneView; the interface isn't the same. Finally, you figure out how OneView works. It could be that you, maybe, have never used a chassis before and then, finally, you understand this Virtual Connect beast and how to set everything up. Then, you're like, "Let's get OneView!" and you switch to OneView. The theories behind it are the same, but the interface is different and the way you set it up is different. So, I will advise being aware of going in.

What we were looking at originally with OneView was the server profiles. We were looking for:

• Something that could provision the server end-to-end with everything configured
• Core management
• Central management
• A way to manage everything
• Have a single plane of glass across all of the server platforms

Those were biggest things that were compelling and drew us to implement OneView.

Central management: That's something we're brand new to at CIBC, i.e., the bank. We never really had a centralized view. We had a very fragmented firmware process across the board with a lot of our hardware. During our refresh cycle, or when trying to keep everything current, that was when we had a real struggle. That's where OneView came into play.

We're still pretty junior into it, so right now our focus with regards to hardware is kind of being displaced now with the cloud. For future releases, it's probably not going to fall into our lap anymore. I probably can't really speak to what we would like to see in future releases, at least not at this point. As much as we've used OneView right now, it's probably not something that we're going to move forward with as a bigger footprint. We're trying to displace ourselves from the hardware platform.

Stability's good. It's an appliance, so really you plug it in and it's configured as it is. There is an advantage to the appliances, as we just put it in. We used a VM appliance and that was a pretty easy implementation. We just had to give it a compute and everything else was done for us.

Scalability is good. Right now, we're still at a small footprint. We are expanding over to another side of the bank that is also using OneView, so we're sharing the licenses. But we found that there were options. We sort of designed it so that we could scale out. We are making a central point server with a bunch of OneView nodes, so that we can still talk about everything at one central source, instead of being continually fragmented.

I did not use technical support. Right now, we are still engaged with professional services, so we had the support right on-site.

We knew we needed to invest just because of the fragmentation issue. We noticed that every time there was an incident or occurrence, it was firmware related. Generally, when you open an incident ticket with any hardware vendor, that's usually the first question, as well as any of the stability issues behind it.

We wanted to make sure that we could rule that out on a currency, on a release schedule, so we could say, "Yep. Because the servers are having scope, we're going to release it on this schedule. Once a year, twice a year, whatever it is." We didn't have a platform existing at that time to do that for us, and that's when we looked at OneView.

I was involved in the initial design. So a few things we generally look at from the engineering space are:

• How do we scale?
• How do we manage this?
• How do we manage the currency?
• How do we expand on it if we need to change the footprint and change direction?
• Can we do this easily, or is this a tear down or rebuild?

We didn't evaluate other options for this space. OneView is kind of the direction given by HPE, and we were using HPE servers. We didn't really have any necessity to look at other vendors.

I would definitely consider it for a colleague who had the same challenges as we did. Obviously, different companies have different challenges. But if they are dealing with similar challenges with regards to a fragmented footprint and currency-wise, OneView is a nice choice. It is:

• Visually appealing
• Easy to use
• Easy for managing servers going forward
• Easy for building servers at a profile level, versus going in traditionally and configuring all that stuff. It can automate all that stuff.

So if those were the challenges they are having, I would say OneView is a good place for them to look.

When selecting a vendor, I think relationship is very important. We want to make sure that our vendor is as intimate with us as we are with them. For them to understand our needs, we need to know what they can offer so that they can be transparent on what they can offer or provide partners that could offer the service to help everything we need efficiently. So that's really number one for me.

It's a little bit of unfair analysis. We weren't able to take this solution to the max. We put it in. We did a small footprint. It worked very well. But could I tell you what would happen at 3,000 servers or 5,000 servers? I wouldn't have an answer for you on that one. There is probably the potential, but I don't have an answer.