Bug 1313369
Summary: | VM parameters set in Edit running VM, are not updated after VM restart. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Ilanit Stein <istein> | ||||||
Component: | BLL.Virt | Assignee: | Shmuel Melamud <smelamud> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | meital avital <mavital> | ||||||
Severity: | urgent | Docs Contact: | |||||||
Priority: | urgent | ||||||||
Version: | 3.6.3.3 | CC: | achareka, ahadas, bugs, ebenahar, eedri, jniederm, mastermind-muell, mavital, mgoldboi, michal.skrivanek, nsimsolo, rgolan, s.kieske, slitmano, smelamud, tjelinek | ||||||
Target Milestone: | ovirt-3.6.4 | Keywords: | Regression | ||||||
Target Release: | 3.6.4 | Flags: | rule-engine:
ovirt-3.6.z+
rule-engine: blocker+ mgoldboi: planning_ack+ tjelinek: devel_ack+ mavital: testing_ack+ |
||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 3.6.4-2 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2016-04-05 13:54:31 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1238742, 1317258, 1320879 | ||||||||
Attachments: |
|
Description
Ilanit Stein
2016-03-01 13:36:27 UTC
Created attachment 1131945 [details]
Update guaranteed mem to 3047M, then restart
This engine.log contain only the relevant part for updating guaranteed memory,
while VM is up, and then VM powered off & started.
This should be solved by https://bugzilla.redhat.com/show_bug.cgi?id=1238742 -> leaving this opened for independent verification. This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. The problem see to be more wide, and not just related to guaranteed memory. Update of every VM parameter, that require VM restart, in order to be implemented, while VM is up, is not seen after VM restart. The problem is that next run snapshot is updated with VM parameter new value, but in the restore snapshot the new value is not set. rhevm 3.6.3.2-0.1 has this bug. latest rhevm 3.5 vt20.5 (rhevm 3.5.8-0.1) do not have this bug. As per Ilanit's request, describing the reproduction steps for a related bug that reproduced on 3.5: 1. Run VM 2. Edit the VM while it is running and change it to stateless (confirm that this change will be applied on next run) 3. While the VM is still running, edit the VM again and change its name -> you will get an error that the creation-date of the VM is changed all patches merged, moving to modified Please note that the part described in Comment 7 has been split of this bug since it is not that urgent and have been postponed to 3.6.5: https://bugzilla.redhat.com/show_bug.cgi?id=1315603 I've checked the flow in comment #7 on rhevm 3.5 vt20.5 (rhevm ger Version: 3.5.8-0.1.el6ev) Indeed, there is the additional parameter, creation-date, that exist on the changed items list, though it was not changed (we have a bug for that - bz 1238742 but after VM restart, the VM is marked as stateless, meaning the restore snapshot does work. In the description of this bug, on rhevm 3.6, the restore snapshot (after VM power cycle) do not contain the changes made in Edit VM, while it was running. Therefore, I see it that the behavior is different between rhevm 3.5 and rhevm 3.6 Shmuel, Roy, referring to patch 54280 - shouldn't cpuProfileId be added to the OVF? How does it behave when you take the snapshot, change the profile and then try to restore? We discussed this with Arik and decided that cpuProfileId shouldn't be part of the snapshot. It is not part of VM's state and references CPU profile which is external to the VM. Roy, what do you think? I would agree, but I also think that then it should not actually be configurable form within the Edit VM dialog, but rather elsewhere (e.g. like network details in a separate subtab) Maybe too big change for now, but it would be make more sense. *** Bug 1317657 has been marked as a duplicate of this bug. *** fails on edit VM in latest build, reopening Try to verify on version: 3.6.4-0.1.el6 Edit VM failed, Can't update VM parameters, Please see log attached 2016-03-17 14:38:50,252 WARN [org.ovirt.engine.core.utils.ObjectIdentityChecker] (org.ovirt.thread.pool-6-thread-3) [792e92a7] Field 'clusterCompatibilityVersionOrigin' can not be updated when status is 'Down' 2:51 2016-03-17 14:38:50,252 WARN [org.ovirt.engine.core.utils.ObjectIdentityChecker] (org.ovirt.thread.pool-6-thread-3) [792e92a7] ObjectIdentityChecker.IsUpdateValid:: Not updatable field 'clusterCompatibilityVersionOrigin' was updated 2:51 2016-03-17 14:38:50,252 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (org.ovirt.thread.pool-6-thread-3) [792e92a7] CanDoAction of action 'UpdateVm' failed for user SYSTEM. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,VM_CANNOT_UPDATE_ILLEGAL_FIELD Created attachment 1137483 [details]
Engine log
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release. *** Bug 1319463 has been marked as a duplicate of this bug. *** *** Bug 1319491 has been marked as a duplicate of this bug. *** *** Bug 1319480 has been marked as a duplicate of this bug. *** *** Bug 1319339 has been marked as a duplicate of this bug. *** note a spin-off bug 1320879 for stateless VMs with disks Verified on version: 3.6.4.1-0.1.el6 I checked several parameters like guaranteed memory, graphics protocol, number of Monitors, etc. On several VM (rhel,windows). It seems like it works good. I found one issue with stateless VM - https://bugzilla.redhat.com/show_bug.cgi?id=1320879 *** Bug 1321187 has been marked as a duplicate of this bug. *** |