CPU cores per socket setting not functional about cloudstack

[rohityadavcloud]

Tentatively marked for 4.11.1.0 milestone, for testing this we'll require a pro version of XenServer. @DagSonsteboSB @PaulAngus do we have a test env to test a fix against?

[bdonnahue]

@PaulAngus is this still an issue? With XCP-ng, is a XenServer Pro license still required? Could the default behavior be to specify cores rather than sockets?

[rohityadavcloud]

@bdonnahue we'll need to test this, if you've a XCP-ng setup, can you test?

[bdonnahue]

@rhtyd I am happy to test but I want to clarify some things and ask some dumb questions. Are you on the slack channel?

[bdonnahue]

@rhtyd any updates? Building cloudstack from source was more complicated that I thought. I have not been able to make any progress here

[rohityadavcloud]

Let's revisit this after 4.11.2.0 gets released. /cc @DagSonsteboSB @PaulAngus

[bdonnahue]

Sounds good, is there a scheduled release date @rhtyd ?

[rohityadavcloud]

@bdonnahue there is no strict date however we were aiming for late-oct, mid-nov; but we have had blockers/bugs because of which we're at RC4.

[bdonnahue]

@rhtyd ok. I will reach out again in a few weeks to see how things are going. Thanks for the help on this!

[andrijapanicsb]

Still exists for 4.11.2 with XCP-NG 7.4 - parameter is ignored, and it's always 4 sockets.

[asender]

Confirmed this issue with Xenserver 7 and Cloudstack 4.11.3

       nameLabel: Async.VM.start_on
 nameDescription:

allowedOperations: []
currentOperations: {}
created: Mon Feb 18 10:11:51 AEDT 2019
finished: Mon Feb 18 10:11:51 AEDT 2019
status: failure
residentOn: com.xensource.xenapi.Host@904b9a65
progress: 1.0
type:
result:
errorInfo: [INVALID_VALUE, platform:cores-per-socket, VCPUs_max must be a multiple of this field]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []

[ToonGeneral]

We have this working with:
XS 6.5 and CS 4.8
XS 6.5 and CS 4.11

Given the OP said they had the issue with 6.2, I am wondering if you're just missing something?

To get it working:

• shutdown the VM
• delete the 'platform' row for this VM ID in user_vm_details
• create a cpu.corespersocket for this VM ID in user_vm_details
• boot the VM from CS
• the 'platform' row is rebuilt from XS
• cores will be whatever you set it to

Obviously it would be much nicer if CS just supported this, but it is possible to get it working.

[bdonnahue]

Hey, thanks for sharing that info about the workaround while we wait for a better solution.

[mschaepers]

We have this working with:
XS 6.5 and CS 4.8
XS 6.5 and CS 4.11
Given the OP said they had the issue with 6.2, I am wondering if you're just missing something?
To get it working:

• shutdown the VM
• delete the 'platform' row for this VM ID in user_vm_details
• create a cpu.corespersocket for this VM ID in user_vm_details
• boot the VM from CS
• the 'platform' row is rebuilt from XS
• cores will be whatever you set it to

Obviously it would be much nicer if CS just supported this, but it is possible to get it working.

Hi ToonGeneral,
can you share the commands in the database? I'm not sure if I'm doing the DB Update correct ;)

ok, got it:
select * from user_vm_details where vm_id= \g
delete from user_vm_details where id=

set @vmuuid='66bec96f-4694-463e-a920-1d99ef29f23d';
set @vmcores='4'
insert into cloud.user_vm_details (vm_id,name, value) (select i.id,'cpu.corespersocket',@vmcores from cloud.vm_instance i where i.uuid=@vmuuid);

[mschaepers]

okay, this seems not to survive a server restart (with shutdown).
After powering on the server is keeps changing back to the original behaviour

[bdonnahue]

Confirmed, it does not support reboots

[ToonGeneral]

Not sure what you guys are doing, but it works fine for us. Survives a reboot through CS fine.

@mschaepers your SQL looks correct, except don't delete * from user_vm_details. You only need to delete the platform value. I don't know if that's what is causing your issue.

I can also confirm this is working using the new UI controls in 4.11. The VM needs to be off and you can then delete the platform entry and add cpu.corespersocket through the UI. Still works on reboot.

[mschaepers]

My original post is missing in the second statement that I delete just platform After modifying it I do see the new platform value with the correct cores. But as soon as the machine gets turned off a new platform value (with new ID) get’s written back to SQL. I will try to check if the results when adding it through the UI. Just wondering if something from the template gets inherited?

…

________________________________ Von: ToonGeneral <[email protected]> Datum: 24. März 2019 um 21:22:24 MEZ Bis: apache/cloudstack <[email protected]> Cc: Mauricio Schäpers <[email protected]>, Mention <[email protected]> Betreff: Re: [apache/cloudstack] CPU cores per socket setting not functional (#2583) Not sure what you guys are doing, but it works fine for us. Survives a reboot through CS fine. @mschaepers<https://github.com/mschaepers> your SQL looks correct, except don't delete * from user_vm_details. You only need to delete the platform value. I don't know if that's what is causing your issue. I can also confirm this is working using the new UI controls in 4.11. The VM needs to be off and you can then delete the platform entry and add cpu.corespersocket through the UI. Still works on reboot. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#2583 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AVEldcqlylTRYwrSG2uU0n5xsXLS2KPMks5vZ98RgaJpZM4Tbrsa>.

[mschaepers]

I’m using a fork of Cloudstack. Just to be sure that we are taking about the same, which UI controls you are talking about exactly? Can you share a screenshot?

…

________________________________ Von: ToonGeneral <[email protected]> Datum: 24. März 2019 um 21:22:24 MEZ Bis: apache/cloudstack <[email protected]> Cc: Mauricio Schäpers <[email protected]>, Mention <[email protected]> Betreff: Re: [apache/cloudstack] CPU cores per socket setting not functional (#2583) Not sure what you guys are doing, but it works fine for us. Survives a reboot through CS fine. @mschaepers<https://github.com/mschaepers> your SQL looks correct, except don't delete * from user_vm_details. You only need to delete the platform value. I don't know if that's what is causing your issue. I can also confirm this is working using the new UI controls in 4.11. The VM needs to be off and you can then delete the platform entry and add cpu.corespersocket through the UI. Still works on reboot. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#2583 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AVEldcqlylTRYwrSG2uU0n5xsXLS2KPMks5vZ98RgaJpZM4Tbrsa>.

[ToonGeneral]

sorry @mschaepers just don't get the same symptoms. We reboot instances all the time and they don't lose the setting.

CS 4.11 interface:

[ToonGeneral]

You need to stop the instance, for the Settings tab to appear.

[mschaepers]

@ToonGeneral thanks, never noticed the setting menu!

as you can see, this is the "new" platform value which get's written back after shutdown (even if the instance was running with the correct settings, in my case 4 cores per socket).
one difference I'm spotting is that we utilize custom service offerings.

@bdonnahue you're seeing the same behaviour. Are you utilizing custom service offerings as well?

However, I will forward this here to your professional support and will keep you updated about the solution.

[progiss]

Hello,
We have the same problem with version 4.13 and KVM hypervisors.
How can we solve this problem because we are trying to create offering services with 45 cores and it affects only 2 cores

[DaanHoogland]

there is a PR out for 4.14 that fixes this for KVM: #4497

[AlexanderKgr]

this is still happening with 4.15.0 and xcp-ng

[DaanHoogland]

The PR i mentioned is merged in the 4.14 branch @AlexanderKgr . If you need to it in 4.15 please test a nightly build, Otherwise it should be fixed in any upcoming release.

[DaanHoogland]

@AlexanderKgr can you please check if this is still an issue on a recent 4.15 or on main and close if appropriate?

[rohityadavcloud]

A PR claiming to fix this issue #4497 has been merged.
@AlexanderKgr @DagSonsteboSB please test 4.15.1/4.14.1 and re-open this if not satisfied, thanks.