Hide Forgot
Description of problem: Update VM OS type from RHEL to Win7 failed. Versions: RHEVM: 3.6.3.4-0.1.el6 Host: OS Version:RHEL - 7.2 - 10.0.el7ev Kernel Version:3.10.0 - 327.10.1.el7.x86_64 KVM Version:2.3.0 - 31.el7_2.8 LIBVIRT Version:libvirt-1.2.17-13.el7_2.4 VDSM Version:vdsm-4.17.23.1-0.el7ev SPICE Version:0.12.4 - 15.el7 Tested from UI works ok. output: <fault> <reason>Operation Failed</reason> <detail>[Cannot edit VM. Invalid time zone for given OS type.]</detail> </fault> Engine log: 2016-03-20 15:33:44,595 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-12) [] Operation Failed: [Cannot edit VM. Invalid time zone for given OS type.] 2016-03-20 15:33:44,605 INFO See also: https://bugzilla.redhat.com/show_bug.cgi?id=1319444
*** Bug 1319482 has been marked as a duplicate of this bug. ***
*** Bug 1319444 has been marked as a duplicate of this bug. ***
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Note that this happens because we (the backend) apply a validation to incoming virtual machines: @ValidTimeZone(groups = {CreateEntity.class, UpdateEntity.class, ImportEntity.class, StartEntity.class}) public class VmBase implements ... { ... } This validation requires that the "timezone" property be compatible with the operating system. In this particular case the VM had a Linux operating system, and the program is trying to set it to "windows_y". As a result the time zone currently used by the VM isn't compatible with the new operating system, and the update fails. There isn't much that the API can (or should) do here: if the backend decides that this isn't a a valid update then the API should just report it. For this update to succeed the user needs to send simultaneously the new operating system and a new time zone that is compatible with that operating system. Either that or we change the backend so that when the operating system is updated the time zone is automatically changed to a default compatible time zone. In any case, this isn't an API bug, so I'm moving it to the backend.
Does it work when you're not switching linux/windows but "stay within" the family? e.g. win7 to win8 change?
I tested: Windows_x to Windows_y - PASS Linux_a to Linux_b - PASS Note: I see that the time zone is set to default after update os type. (via UI)
(In reply to Israel Pinto from comment #6) > I tested: > Windows_x to Windows_y - PASS > Linux_a to Linux_b - PASS so everything works as it should, thanks for confirmation:) Each family has a different set of TZs hence you need to supply the new TZ when you switch between Linux and Windows. The error "Invalid time zone for given OS type" seems descriptive and understandable enough. > Note: > I see that the time zone is set to default after update os type. (via UI) yes, that is the behavior (it's not strictly necessary when changing OS within the family but IIRC we did it for the sake of simpler code)