[ovirt-users] Unable to change compatibility version due to hosted engine

Simone Tiraboschi stirabos at redhat.com
Thu Dec 15 11:13:13 UTC 2016


On Thu, Dec 15, 2016 at 12:04 PM, Renout Gerrits <mail at renout.nl> 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 at redhat.com>
> wrote:
>
>>
>>
>> On Thu, Dec 15, 2016 at 10:33 AM, Renout Gerrits <mail at renout.nl> 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 at 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 at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20161215/a26fd261/attachment-0001.html>


More information about the Users mailing list