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?

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@redhat.com> wrote:

On Thu, Dec 15, 2016 at 10:33 AM, Renout Gerrits <mail@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@internal. Reasons: VAR__TYPE__STORAGE__POOL,VAR__ACTION__UPDATE,$ClustersList Default,ERROR_CANNOT_UPDATE_STORAGE_POOL_COMPATIBILITY_VERSION_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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users