Bug 1303450
| Summary: | [REST] Increasing the CPU sockets to a amount of CPU's that the host doesn't have, Shouldn't be possible via REST | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Shira Maximov <mshira> | ||||||
| Component: | General | Assignee: | Marek Libra <mlibra> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Shira Maximov <mshira> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 3.6.3 | CC: | bugs, mavital, michal.skrivanek, mshira | ||||||
| Target Milestone: | ovirt-4.1.0-alpha | Flags: | rule-engine:
ovirt-4.1+
rule-engine: planning_ack+ rule-engine: devel_ack+ mavital: testing_ack+ |
||||||
| Target Release: | 4.1.0.2 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: |
Cause: User could set vCPU count of a running VM to higher number than available on the host.
Consequence: Inconsistent state achieved
Fix: Update of running VM's CPU count fails when adding more CPUs than available on the host.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-02-01 14:55:40 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
comment: the VM need to be pin to a specific host Created attachment 1119927 [details]
rest logs
Shira - why is it high severity? What is the user consequence? (In reply to Yaniv Kaul from comment #3) > Shira - why is it high severity? What is the user consequence? There is no Validation in REST, if the user will run nproc or top commands in the VM he will see the number of CPU's that you enter in REST, even tough the VM can't have this amount of CPUS (because the host doesn't have this resources). (In reply to Shira Maximov from comment #4) > (In reply to Yaniv Kaul from comment #3) > > Shira - why is it high severity? What is the user consequence? > > There is no Validation in REST, if the user will run nproc or top commands > in the VM he will see the number of CPU's that you enter in REST, even > tough the VM can't have this amount of CPUS (because the host doesn't have > this resources). OK (it shouldn't be in REST but in the backend), but I still don't see why it is a severe bug. we explicitly go through scheduling filters in this case - we should do that for REST path as well The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified. Verified on :
oVirt Engine Version: 4.1.0-0.0.master.20161120231325.gitba51756.el7.centos
verification steps :
PUT request in REST:
url:/ovirt-engine/api/vms/vm-id
body:
<vm>
<cpu>
<topology>
<sockets>16</sockets>
</topology>
</cpu>
</vm>
result:
<fault>
<detail>
[The requested number of vCPUs is not available on the host the VM is running on]
</detail>
<reason>Operation Failed</reason>
</fault>
|
Created attachment 1119926 [details] engine log Description of problem: Increasing the CPU sockets (hot plug cpu) while VM is running to a amount of CPU's that the host doesn't have, is possible via REST and it shouldn't be possible. Version-Release number of selected component (if applicable): Red Hat Enterprise Virtualization Manager Version: 3.6.3-0.1.el6 How reproducible: 100% Steps to Reproduce: 1.Running VM with 1 socket * 1 core (Host total cpu is 6 ) 2. Try to increase the socket to 16 - in UI not possible but in REST it is possible. 2016-01-31 21:14:18,854 - MainThread - vms - DEBUG - PUT request content is -- url:/ovirt-engine/api/vms/735366b0-49a5-4425-9e7a-b85dab01281a body:<vm> <cpu> <topology sockets="16"/> </cpu> </vm> 3. Actual results: The put request worked Expected results: The put request should work Additional info: