OneView 4.20 - 8x vCPU and 24GB RAM?

[rmay_bk]

Just upgraded from 4.10 to 4.20 and seeing an error "The current appliance configuration is not supported. It does not meet the minimum required amounts of compute resources or memory. The appliance will have degraded performance and may become unusable until the configuration is corrected."

It's asking for 8x vCPU and 24GB vRAM in the details.  WOW!  This VM currently has 4x vCPU and 16GB vRAM allocated.  It's never went beyond 7GB memory active or 20% CPU utilization.  What's driving this decision?

[Kamalji]

The support matrix document for Oneview 4.2 have mentioned 

Appliance VM and host requirements on Page 5 onwards to refer which need to be met before migrating .

https://support.hpe.com/hpsc/doc/public/display?docId=a00059959en_us

[sysadmin4151]

Didn't answer his question of why it's neccessary.

8 vCPU and 24 GB is ridiculous, especially if you only want to monitor hardware health of a handful of enclosures.

Should be a few different spec options, say small, medium, large environments and monitoring vs managing profiles, etc.

[ChrisLynch]

We have a lot of customers that have been plagued by upgrade and operational issues when the appliance resour e allocation was smaller. So, we set this for all VM appliance installations. Are you not able to allocate these resources? Customers we have provided feedback have told us they don't have issues with resource allocation. And not, they are not from our largest enterprise customers. But a wide range of customers and Datacenter sizes.

[fixme]

Overallocation goes against virtualization best practices and throwing uneeded resources at a software problem to get around upgrade issue seems unreasonable. If utilization warrants the increase in size I'm ok with that but if its being done to get around upgrade issues that is unacceptable.

**Edit - And I should clarify overallocation in regards to right sizing. An over provisioned virtual machine just takes time on the scheduler and increases CPU ready time.

[ChrisLynch]

You mischaracterized my statement.  There are only so many different customer scenarios we can test for.  During the lifecycle of our product, we have found in quite a number of cases that the VM can become starved during a number of operations.  Increasing the size of the VM was a way to help address.  Can software be optimized to improve efficiencies?  Of course.  Did I preclude that in my statement to indicate we aren't optimizing where we can?  No.  Your feedback is important to hear.  Please know that we don't just increase resource requirements just for the sake of it, and without understanding the greater impact it can have with customers environments.

[Kevin4]

I would think I'm a small shop with about 20ish esx servers in different datacenters.   I'm thinking of trying the OneView, but I feel the requirements is a bit steep for monitoring a small environment.  My VirtCenters use less system resources.   A small, medium, large sizing is needed.  I have web servers with 4 cores and 24 GB RAM but they have 15,000 people trying to access it.

[shineknox]

We don't even have 40 physical servers to monitor. This is a typical vendor response to mask their issue and let the customer be the one that suffers. I feel in the floor laughing when I saw the prerequisites; unacceptable.

[rmay_bk]

I kept ours at 4x vCPU and 16GB.  It's been fine so far, other than complaining about the situation in the alarms.

We're only using it for monitoring at this time, though.

[rmay_bk]

So here's an update to our resource allocation story.  We're using 4.20 for only monitoring (no management).  We have four enclosures ranging from about half populated to fully populated plus some rack servers -- total server nodes under monitoring is around 150.  We've been running for weeks at 2x vCPU and 12GB RAM and everything seems to be running OK.  Startup is a bit slow but everything seems fine otherwise.  1x vCPU is not usable and neither is 8GB of RAM.

[edit: I found a way to break it and I'm trying 16GB now.]

I wouldn't try doing this if OneView were mission-critical.  For my group it's just a helpful tool among many that we use.

[meant0m]

I experienced the same thing after I updated from 4.01.04 to 4.20.01.01.  My appliance also has 4x vCPU and 16GB vRAM allocated.  I decided to just ignore it and continue to update to 5.00.01.  I use it for mostly just monitoring of about 80 DL servers and 5 C7000 enclosures.

At any rate, the update completed and I will continue with 4 vCPUs and 16GB of RAM unless i reall see a need to increase it.  Just wanted to report that the updates worked and appears to be functioning just fine without the increase.

[pjo65]

You can easilly have poorer performance if you increse vcpu allocation! Just watch what happens to the cpu ready valu going from 2->4 and 4->8! Ok! If you have a situation not common in the realworld i.e. no overprovision what so ever! You will be fine. But when you apply this ludicrous vcpu demand in the real world where you typically have 3:1 ratio, the going from 4->8 vcpu is the worong way. I can easilly live with higher cpu utilisation rater than high cpy ready value that can easilly be above 50- or 200 mS! The the machine will feel really sluggish! Your estimation is true for a physical machine but in the virtual world increasing vcpu usually has negative impact on performance!