Post

2 followers Follow
0
Avatar

CPU Capacity option

In v2.0, the 'Capacity' option seems to have replaced Instance templates. This is fine if it worked as expected.

I've tried playing around with this, but while the memory selection is fine, the CPU selection is now harder. I like the idea of end users being able to select a number of CPU's from a list or slider, but only if it's simple!

If I set the 'CPU' selection as fixed to 1, but set the vCPU to between 1-4,then deploy a VM with the vCPU set to '2', I end up with a VM with 2 x 1 core virtual sockets (not what I wanted). If I set vCPU fixed to 1, then modify the CPU setting, the slider is now allowing settings in the 1.xx range (not logical for the user). I've tried various ways of configuring the Sunstone template without success. The VMware template has a default setting of 1 socket, 1 core.

So, what I'm saying is, I need a simple way for end-users to just specify the number of CORES for the VM. Keep the CPU sockets locked at 1 in the template if possible.

Can you do this? I've checked the OpenNebula docs, but that's a bit vague as well.

Tony Barrett

Please sign in to leave a comment.

11 comments

0
Avatar

I've attached a screenshot of what I'm trying to achieve, and why it's wrong. So, you can see that in this case, with template capacities for the
CPU fixed to '2' and vCPU set to '2', I end up with 2 sockets with 1 core per socket, when what I actually want is 1 socket and a flexible selection of 1-4 cores.

How do I achieve this?

 

Tony Barrett 0 votes
Comment actions Permalink
0
Avatar

There are two separate issues here:

 - The ability to select the number of sockets per CPU and not just the number of CPUs for the guest OS

 - Improve the user experience by hiding user selection of physical CPUs

We will work in this features in future releases. Meanwhile we advise to use fixed CPU selection, and give the ability to select VCPU to end users (knowing that you cannot select the number of sockets per CPU).

vOneCloud Support Team 0 votes
Comment actions Permalink
0
Avatar

Thanks for the suggestion while you consider how to implement this in a future release.

What I've found though, is that if I fix the 'CPU' to 1 (which I assume is the number of sockets), and select '2' from a sliding selection of 1-4 for the vCPU (cores), I still end up with a 2 socket VM with 1 core per socket, which is exactly the opposite of what I'd expect.

I also tried 1 CPU with 4vCPU's and ended up with 4 sockets with 1 core per socket.

Here's the really strange thing. If I lock the vCPU to '1', and select '2' from the CPU list of 1,2,4 (ie, the reverse), I get a 1 socket VM with 1 core!

Tony Barrett 0 votes
Comment actions Permalink
0
Avatar

Finally, the part I'm having difficulty explaining. I have other templates with 'fixed' capacities, so in this case CPU set to '2' and vCPU set to '2'. What I end up with there is a VM with 1 socket and 2 cores. Another template has '4' CPU and '4' vCPU, and I end up with a single socket quad-core VM. This is sort of what I want, but the 'CPU' setting seems wrong somehow.

Tony Barrett 0 votes
Comment actions Permalink
0
Avatar

One more thing. I just re-configured one of the 'flexible' capacity templates I've been working with back to fixed with '2' CPU and '2' vCPU (a config I new gave 1 socket and 2 cores in another VM).

What did I get when I provisioned from this template? Well, what I got was 2 CPU sockets with 1 core each! Aaaarrghh!

Tony Barrett 0 votes
Comment actions Permalink
0
Avatar

I second this. vCPU / CPU are just too hard to understand for normal user who just wants to get VM up and running.

When you set CPU to fixed value of 1 and let users set amount of vCPUs it works but it seems like it has just one core when it in fact has something else. On attached picture I set vCPU value to 2 and would you see it by looking at virtual machine? for me it seems like it has only one core.

Is there way to hide CPU field as it makes no sense for normal user?

Jaska Kamila 0 votes
Comment actions Permalink
0
Avatar

Ok, honestly, I'm loving the new features in v2.0, but this CPU capacity problem is an absolute deal-breaker for me. Flexible capacity management of VM's at deployment is critical to operation. I don't want to create 10 x as many fixed capacity templates, but it's just not working as expected.

The old method of defining templates was a bit clunky in comparison, but it worked. If I wanted to create a template for a single socket VM with 4 cores, I'd set the template instance_type to CPU: 4 vCPU: 4, which corresponds to this VMware KB article;

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010184

In v2, if I set CPU: 4, vCPU: 4 I get a 4 socket CPU with 1 core per socket! I've tried playing around with the cupid.coresPerSocket setting in the VM template, but this is not a fix, and it's still confusing and unneccesary to have to do this.

I need a way to lock the socket count on all VM templates, with a flexible way of assining a number of cores per socket (list or slider). If I can't do this, I'm either going to have to wait for a version that fixes it (delaying rollout), or go back to v1.8. The whole point of this system is as a flexible, SIMPLE, self-provisioning system for the user.

Tony Barrett 0 votes
Comment actions Permalink
0
Avatar

Thanks for all the detailed feedback. We understand that the mechanism to select virtual cpus in 2.0 is too confusing, we will work hard to fix this for the next release.

vOneCloud Support Team 0 votes
Comment actions Permalink
0
Avatar

Thanks for confirming you'll try and do something about this in the next release - it will help end users greatly.

In the meantime, is there *anything* that can be done to provision VM's using the correct socket/core count? Even if I have to make a low-level change to ensure only a single socket is used, but allow the end user to select a specific core count.

Making plans to simpify CPU selection is great, but it doesn't help me right now. From what I can tell from my testing, v2 is *not* proivisioning VM's using the correct core selection, certainly not in the same way v1.8 did anyway.

Tony Barrett 0 votes
Comment actions Permalink
0
Avatar

One other issues I've just discovered. I configured a couple of templates so that the CPU was fixed to 1, but vCPU had a range of 1-4. I provisioned a VM with 4 vCPU from the template. As we've discovered, the provisioned VM had 4 sockets with 1 core per socket, so technically is quad CPU (I won't call it quad-core).

In cloud view, the user only sees the VM with 'x1' CPU, which also means their quota also only shows as 1 CPU used, even though I've configured the user with a 4 CPU max quota. So, essentially, they get a quad-CPU VM that shows as x1 in their Dashboard and only see 1 CPU used in their quota. This means they could actually configure 4 quad CPU VM's all within their 4 CPU quota!

Tony Barrett 0 votes
Comment actions Permalink
0
Avatar

I've just upgraded to 2.0.1, and was excited to see that the particular feature identified in this thread sounded like it had been fixed according to the release notes.

So, I've just tried modifying a template to see if this is true. It now appears that the 'CPU' value is either ignored or just not displayed when provisioning from Cloud view. If I set the CPU as 'fixed' to 1, but the vCPU as a range 1-4, all I can see is the option to select the vCPU, which is definately simpler and sounds like it should work, but, in the case of selecting 2 vCPU's, I still get a dual socket VM rather than a dual core VM as discussed. Is this the expected behaviour in 2.0.1? Are there any plans to allow multi-core VM's rather then multi-socket when selecting CPU capacity?

It seems like rather than the identified issue being 'fixed' the behaviour is now different.

Tony Barrett 0 votes
Comment actions Permalink