1:04 p.m.
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(a)redhat.com>
wrote:
On Thu, Dec 15, 2016 at 10:33 AM, Renout Gerrits <mail(a)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_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
>
>