Bug 1128456 - [REST API]: vcpu socket number can be set to a value larger than maximum allowed.
Summary: [REST API]: vcpu socket number can be set to a value larger than maximum allo...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-api
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.5.1
Assignee: Roy Golan
QA Contact: Ilanit Stein
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-10 14:27 UTC by Ilanit Stein
Modified: 2016-02-10 19:50 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 16:13:26 UTC
oVirt Team: Virt
Embargoed:


Attachments (Terms of Use)

Description Ilanit Stein 2014-08-10 14:27:41 UTC
Description of problem:
For a VM with max vcpu 4 sockets possible, update VM operation, via REST to 10 sockets succeeds, though the socket number was not updated actually to 10.

Version-Release number of selected component (if applicable):
ovirt-engine 3.5 - rc1

Expected results:
Update VM to a number of sockets larger than the maximum possible operation should fail.

Comment 1 Roy Golan 2014-08-11 23:39:04 UTC
hot plugging is delicate command which could fail in lots of cases and we don't fail the whole update. we just fall back to the old value.

e.g if you update both the vm name and sockets you would still see the change of name. 

this is the behaviour by design.

Comment 2 Ilanit Stein 2014-08-13 06:54:31 UTC
The following event appear for sockets=10 (when max possible is 4): 
	
"Failed to hot set number of CPUS to VM test5. Underlying error message: Cannot hot set cpus VM. There are no available running Hosts with enough cores in VM's Cluster ."

For setting sockets nubmer above 16, update VM cpu hotplug operation fail on:
"Cannot edit VM. Max number of sockets exceeded"

Comment 3 Michal Skrivanek 2014-08-18 12:13:30 UTC
looks ok, 16 is the absolute max we support (so it's easy to check)
proposing notabug

Comment 4 Ilanit Stein 2014-08-19 13:01:31 UTC
Please add feature page that the expected behaviour is that when updating with socket number larger than the VM max, the update VM operation will succeed,
and the new value will not be updated into the DB.

Comment 5 Michal Skrivanek 2014-10-30 15:47:15 UTC
Roy, is this in progress for 3.5.1?

Comment 6 Roy Golan 2014-11-05 10:34:50 UTC
(In reply to Michal Skrivanek from comment #5)
> Roy, is this in progress for 3.5.1?

wiki updated accordingly
http://www.ovirt.org/Hot_plug_cpu#Update_Vm_Command_-_Error_handling

per Ilanit's request we should care for proper documentation. Do you expect some change in the behaviour?

Comment 7 Michal Skrivanek 2014-11-10 09:08:05 UTC
sounds good to me, Ilanit, can you check the page?

Comment 8 Ilanit Stein 2014-11-12 07:24:28 UTC
In general the error documentation looks ok.
I suggest these cosmetic rephrase:

Update Vm Command - Error handling

The API to hot plug CPU is using UpdateVmCommand. Essentially, if there is a change in topology, a child Command HotSetNumberOfCpus will be called.
If the call to this child command fail, it shall *NOT* abort the parent UpdateVmCommand.

e.g - we want to update a running's VM description, and to hotplug 1 more cpu,
but the number of VM's cpus is already the maximum allowed.

1. the updated values are desctiption and numberOfSockets 
2. UpdateVmCommand saves the description to DB 
3. HostSetNumberOfCpus is called with new number of sockets, but fails
4. UpdateVmCommand checks for the failure and outputs an AuditLog
5. UpdateVmCommand terminates and commit changes to DB with the new description only. The old number of sockets remains unchanged

Comment 9 Sandro Bonazzola 2015-01-21 16:13:26 UTC
oVirt 3.5.1 has been released and since this bug is targeted 3.5.1 and in modified state, it should be included in this release.
Please re-target and move nack to modified if this assumption is not valid for this bug.

Comment 10 Roy Golan 2015-02-04 09:43:56 UTC
no changes need to be done.


Note You need to log in before you can comment on or make changes to this bug.