Description of problem: After upgrading engine and vdsm to version 3.5, editing cluster fail because cpu type does not match. In the clusters tab, cpu type is displayed as: "Intel Haswell" In the edit cluster menu, it is displayed as: "Intel Haswell Family" When you open the edit cluster dialog, the cpu type becomes empty, although it is displayed in the cluster tab. Any change in the edit cluster dialog cannot be saved, becuase the cpu type is not sepcified. Trying to select "Intel Haswell Family" and save fail with this error: Cannot update Cluster and change CPU Cluster name if there are hosts or virtual machines in the Cluster. This CPU name is incompatible with all other available CPUs Removing both RHEL 6.5 hosts from the cluster did not change anything. Removing all virtual machines from the cluster did not change anything. Version-Release number of selected component (if applicable): 3.5.0-0.0.master.20140630172346.git994996b.fc19 How reproducible: Happened once.
Created attachment 913735 [details] edit cluster dialog showing current cpu type and empty cpu type menu
According to Eli, this is related to this: commit 25b963a31619a1471ecd8fd121cfef7c4b1a5043 Author: Amador Pahim <apahim> Date: Fri Mar 21 11:21:15 2014 -0300 core: Fix listing name for Intel Haswell All Intel models are listed as "Intel <Model> Family", except for Haswell, wich does no contain "Family" in its listing name. Fixing. Change-Id: I8a8fd8e270bb23200f0d25f00afa8f7108a0f0a0 Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1079420 Signed-off-by: Amador Pahim <apahim>
Created attachment 913739 [details] engine log while trying to upgrade cluster
Correction - removing all hosts and all virtual machines solved the issue. Previously I removed all host, then added one back to remove the virtual machines. However this still means that a user cannot upgrade becasue the whole point in upgrading is not removing anything :-)
ok, ovirt-engine-backend-3.5.0-0.0.master.20140804172041.git23b558e.el6.noarch I can create CL with Intel Haswell Family without problem (although we don't have a host to add into such CL).
oVirt 3.5 has been released and should include the fix for this issue.