Description of problem: CFME VM Reconfigure, for a Powered OFF VM, with Physical Memory Guaranteed: 1024 MB, and Memory size 2048 MB, as follows: To: Processor Sockets: 1, Processor Cores Per Socket: 4, Total Processors: 4 From: Processor Sockets: 4, Processor Cores Per Socket: 1, Total Processors: 4 Request fail on Error: [Cannot edit VM. Physical Memory Guaranteed cannot exceed Memory Size.] Version-Release number of selected component (if applicable): CFME 5.6.0.11-rc2.2.20160614152915_f315c68 RHEVM-3.6.6.2-0.1.el6 How reproducible: 100% Actual results: Eventually the desired Processor change do not appear in RHEV side. Expected results: Update Processor sockets/Cores per socket should work. Additional info: 0. VM was win2008R2/ISCSI, but bug seems not related to VM OS, since it occurs on non OS/RHEL VMs as well. 1. The guaranteed memory do not exceed Memory size. 2. In evm.log this error do not appear. [----] I, [2016-07-04T02:50:57.201294 #3095:4dbd9f0] INFO -- : <AutomationEngine> <AEMethod vmreconfigure_request_approved> Sending email to <evmadmin> from <evmadmin> subject: <Request ID 1000000000035 - Your request to Reconfigure the Virtual Machine was Approved> but there was a former same Processor change request, when the Physical Memory Guaranteed: 2048 MB, and Memory size 2048 MB, failing with the same error, where this error does appear in evm.log: [----] E, [2016-07-04T02:50:57.323180 #52824:10bb994] ERROR -- : Q-task_id([vm_reconfigure_task_1000000000034]) <RHEVM> Ovirt::Service#parse_error_response Return from URL: <https://10.35.161.51/api/vms/a2e8bc6c-02b6-426f-b382-c11a0c1550db> Data:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <reason>Operation Failed</reason> <detail>[Cannot edit VM. Physical Memory Guaranteed cannot exceed Memory Size.]</detail> </fault>
Created attachment 1175849 [details] evm.log
You can by pass this by configuring memory as well for that vm in the same action - the reason behind this is some strange behavior in ovirt provider which attempt to update the memory as well after the cpu was set (this clearly should not happen)
This bug should be solved by the same fix for bug 1356193
Verified on: RHV-4.0.4.2-0.1.el7ev 5.7.0.1.20160913164703_66caf07
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0012.html