On Thu, Dec 15, 2016 at 10:33 AM, Renout Gerrits <mail(a)renout.nl&gt; wrote: > Hi All, > > We have an environment which we want to upgrade to ovirt 4.0. This was > initially installed at 3.5, then upgraded to 3.6. > Problem we're facing is that for an upgrade to 4.0 a compatibility > version of 3.6 is required. > When changing the cluster compatibility version of the 'Default' cluster > from 3.5 to 3.6 we get the error in the gui: "Cannot change cluster > compatibility version when a VM is active. please shutdown all VMs in the > cluster." > Even when we shutdown all vm's, except for the Hosted Engine we get this > error. > On the hosts a 'vdsClient -s 0 list' is done which will return the HE. > In the engine logs we have the following error: "2016-12-08 13:00:18,139 > WARN [org.ovirt.engine.core.bll.storage.UpdateStoragePoolCommand] > (default task-25) [77a50037] CanDoAction of action 'UpdateStoragePool' > failed for user admin@internal. Reasons: VAR__TYPE__STORAGE__POOL,VAR__ACTION__UPDATE,$ClustersList > Default,ERROR_CANNOT_UPDATE_STORAGE_POOL_COMPATIBILITY_VERSI > ON_BIGGER_THAN_CLUSTERS" > > So problem would be that the HE is in the Default cluster. But how does > one change the compatibility version when the HE is down? > I've tried shutting down the engine, changing the version in the DB: > "UPDATE vds_groups SET compatibility_version='3.6';" and starting the > engine again. > > When I do that and try to start a VM: > 2016-12-09T13:30:21.346740Z qemu-kvm: warning: CPU(s) not present in any > NUMA nodes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > 2016-12-09T13:30:21.346883Z qemu-kvm: warning: All CPU(s) up to maxcpus > should be described in NUMA config > 2016-12-09T13:30:21.355699Z qemu-kvm: "-memory 'slots|maxmem'" is not > supported by: rhel6.5.0 > > So that change was rolled back to compatibilty 3.5. After that we we're > able to start vm's again. > Please note that all hosts and HE are EL7. > > To me this doesn't seem like a strange set-up or upgrade path. Would it > be possible to start the HE in another cluster than Default or is there a > way to bypass the vdsClient list check? > What is the recommended way of upgrading the HE in this case? > Please take a look here: https://bugzilla.redhat.com/show_bug.cgi?id=1364557 > > Kind regards, > Renout > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >

On Thu, Dec 15, 2016 at 12:04 PM, Renout Gerrits <mail(a)renout.nl&gt; wrote: > Hi Simone, > > Do you mean the following? > > - create a new cluster with version 3.6. > - Migrate HE to new cluster > - Shutdown all VM's in old cluster > - change compatibility version of old cluster to 3.6 > - migrate HE back to old old cluster > > In this case the old cluster still thinks that the HE is running in it > due to the ChangeVmCluster action that fails. From what I see this is fixed > in 4.02: https://bugzilla.redhat.com/show_bug.cgi?id=1351533 > But I can't to upgrade 4 yet. Do you know if this fix has been back > ported to 3.6? > Yes, it has been backported to 3.6.9: https://gerrit.ovirt.org/#/c/63377/2 Another option is just to add a new hosted-engine host to the new 3.6 cluster and restart the engine VM there from the hosted-engine CLI. For me it's hard to just try as I will need a maintenance window to > shutdown all vm's. > > Or do you mean something completely different? > > Thanks, > Renout > > On Thu, Dec 15, 2016 at 11:01 AM, Simone Tiraboschi <stirabos(a)redhat.com&gt; > wrote: > >> >> >> On Thu, Dec 15, 2016 at 10:33 AM, Renout Gerrits <mail(a)renout.nl&gt; wrote: >> >>> Hi All, >>> >>> We have an environment which we want to upgrade to ovirt 4.0. This was >>> initially installed at 3.5, then upgraded to 3.6. >>> Problem we're facing is that for an upgrade to 4.0 a compatibility >>> version of 3.6 is required. >>> When changing the cluster compatibility version of the 'Default' >>> cluster from 3.5 to 3.6 we get the error in the gui: "Cannot change cluster >>> compatibility version when a VM is active. please shutdown all VMs in the >>> cluster." >>> Even when we shutdown all vm's, except for the Hosted Engine we get >>> this error. >>> On the hosts a 'vdsClient -s 0 list' is done which will return the HE. >>> In the engine logs we have the following error: "2016-12-08 >>> 13:00:18,139 WARN [org.ovirt.engine.core.bll.st >>> orage.UpdateStoragePoolCommand] (default task-25) [77a50037] >>> CanDoAction of action 'UpdateStoragePool' failed for user admin@internal. >>> Reasons: VAR__TYPE__STORAGE__POOL,VAR__ACTION__UPDATE,$ClustersList >>> Default,ERROR_CANNOT_UPDATE_STORAGE_POOL_COMPATIBILITY_VERSI >>> ON_BIGGER_THAN_CLUSTERS" >>> >>> So problem would be that the HE is in the Default cluster. But how does >>> one change the compatibility version when the HE is down? >>> I've tried shutting down the engine, changing the version in the DB: >>> "UPDATE vds_groups SET compatibility_version='3.6';" and starting the >>> engine again. >>> >>> When I do that and try to start a VM: >>> 2016-12-09T13:30:21.346740Z qemu-kvm: warning: CPU(s) not present in >>> any NUMA nodes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >>> 2016-12-09T13:30:21.346883Z qemu-kvm: warning: All CPU(s) up to maxcpus >>> should be described in NUMA config >>> 2016-12-09T13:30:21.355699Z qemu-kvm: "-memory 'slots|maxmem'" is not >>> supported by: rhel6.5.0 >>> >>> So that change was rolled back to compatibilty 3.5. After that we we're >>> able to start vm's again. >>> Please note that all hosts and HE are EL7. >>> >>> To me this doesn't seem like a strange set-up or upgrade path. Would it >>> be possible to start the HE in another cluster than Default or is there a >>> way to bypass the vdsClient list check? >>> What is the recommended way of upgrading the HE in this case? >>> >> >> Please take a look here: >> https://bugzilla.redhat.com/show_bug.cgi?id=1364557 >> >> >>> >>> Kind regards, >>> Renout >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> >