[ovirt-users] cluster compatibility version 4.7

[Staniforth, Paul]

Hello
  When we try to complete the upgrade to 4.5.1 there is a failure to 
upgrade the cluster to compatibly version 4.7

 Cannot update compatibility version of Vm/Template: [HostedEngine], Message: 
There was an attempt to change Hosted Engine VM values that are locked.

Also somehow the cluster had changed to Cluster Node Type of Virt only but 
there was an error due to started volumes when trying to change the Cluster 
from the WebUI.
I fixed this by changing it in the DB.


Thanks,
  Paul S.


To view the terms under which this email is distributed, please go to:-
https://leedsbeckett.ac.uk/disclaimer/email
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LCHGO57JG3MF4JNKXTHDFBUCK42HCGWT/

[ovirt-users] Cluster compatibility version 4.5 on oVirt 4.4

[tfe...@swissonline.ch]

Hi

Today, I upgraded oVirt from 4.3 to 4.4.3.

After the upgrade, I upgraded the compatibility from 4.3 to 4.4.

I noticed that the cluster config is offering me another upgrade of the 
compatibility to version 4.5.


Up until now, I was under the impression that the compatibility version 
must match the oVirt version.


I am now reluctant to upgrade the compatibility to 4.5, while my oVirt 
version is still at 4.4 (there is no oVirt 4.5 at this time).


Is it safe to upgrade the compatibility in any case, or are there 
certain circumstances, where we should refrain from upgrading it?


I wasn't able to find anything in the documentation.


Kind regards

Toni Feric
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XR4XU55CAL25CYNW7WBWJLIZLQXB4WIZ/

[ovirt-users] Cluster Compatibility Version Upgrading Order

[Roman Last]

Hello!
What sequence of upgrading cluster to 4.3 version?
When i click upgrade on host w or w\o host reboot it just says "Upgrade has 
started for" and nothing after timeout reached. When i force restart host, 
version 4.3 not added. Is that normal?
https://prnt.sc/mki3v8
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4A7VQIDM6GM54XGQRETANU5ACVROYYG/

[ovirt-users] Cluster compatibility 4.1 to 4.2 upgrade

[Demeter Tibor]

Dear Listmember, 

I've just upgrade to my ovirt-hosted-engine from 4.1 to 4.2.3. It was 
successful, but it saw " Data Center XYZ compatibility version is 4.1, which is 
lower than latest engine version 4.2. Please upgrade your Data Center to latest 
version to successfully finish upgrade of your setup." 

My first question is that, it need to do BEFORE or AFTER the node upgrades? 

I haven't upgrade my nodes yet, because after upgrade the live migration does 
not work with some VMs. It seems only affected those VMs that's have big (>8GB 
) memory. It counting to 99 percent and after a while just stopped. 
At this moment I can't stop my affected, productive VMs, so I can't do the 
upgrade of nodes. 
I just wondering, if i do the upgrade to 4.2 , that's maybe repair my the live 
migration function? 

What can I do? 

Centos 7.4, NFS storage, 4 nodes, Hyperconverged hosted engine. 


Thanks in advance, 
Tibor 








___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

Re: [ovirt-users] Cluster compatibility version and major upgrades

[Yaniv Kaul]

On Thu, Mar 2, 2017 at 4:44 PM Yedidyah Bar David  wrote:

> On Tue, Feb 28, 2017 at 10:06 PM, Chris Adams  wrote:
> > Hello again, still working on my upgrade from 3.5...
> >
> > I'm trying to understand the cluster compatibility version setting and
> > how that applies to major upgrades.  Do I have to always raise the
> > compatibility version when I do a major upgrade?
>
> Not immediately.
>

Right, but then people forget to do it later ;-)
Y.


> Doing this will let you use the new features.
>
> >  In other words, when I
> > upgrade from 3.5 to 3.6, do I need to raise it to 3.6 before I upgrade
> > to 4.0 (and then again raise it 4.0 before upgrading to 4.1)?
>
> Each engine version has a set of supported compatibility levels.
> If you run engine-setup and have a cluster/DC with a too-old level,
> it will refuse to upgrade.
>
> >
> > It looks like the 3.6->4.0 EL6->EL7 migration requires the cluster
> > compatibility level to be at 3.6 (if I'm reading things right).
>
> Indeed.
>
> >
> > It appears that when I upgrade to 3.6, I will have to stop all running
> > VMs to raise the compatibility version (and I found an open bug about
> > whether that's possible with the hosted engine).  It sounds like with
> > 4.0, the VMs can be flagged for compatibility and I can reboot them
> > individually.  I have over 80 VMs, many behind a load balancer (for HA
> > and load sharing), but taking them all down will obviously still
> > interrupt service for a while.
> >
> > Is there a safe way around that?
> >
> > I saw someone mention they partitioned their servers and made a new
> > cluster (with the new version), and migrated VMs from cluster to
> > cluster.  Can I do live migrations in that case?  How do I get the
> > hosted engine from one cluster to another (especially with starting at
> > 3.5)?
>
> You'll definitely need hosted-engine downtime, but that's usually not
> an issue. For your other VMs, not sure - I think that if you get a mark
> saying they should be rebooted, they should. See also:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1336527
>
> Best,
> --
> Didi
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Cluster compatibility version and major upgrades

[Yedidyah Bar David]

On Tue, Feb 28, 2017 at 10:06 PM, Chris Adams  wrote:
> Hello again, still working on my upgrade from 3.5...
>
> I'm trying to understand the cluster compatibility version setting and
> how that applies to major upgrades.  Do I have to always raise the
> compatibility version when I do a major upgrade?

Not immediately.

Doing this will let you use the new features.

>  In other words, when I
> upgrade from 3.5 to 3.6, do I need to raise it to 3.6 before I upgrade
> to 4.0 (and then again raise it 4.0 before upgrading to 4.1)?

Each engine version has a set of supported compatibility levels.
If you run engine-setup and have a cluster/DC with a too-old level,
it will refuse to upgrade.

>
> It looks like the 3.6->4.0 EL6->EL7 migration requires the cluster
> compatibility level to be at 3.6 (if I'm reading things right).

Indeed.

>
> It appears that when I upgrade to 3.6, I will have to stop all running
> VMs to raise the compatibility version (and I found an open bug about
> whether that's possible with the hosted engine).  It sounds like with
> 4.0, the VMs can be flagged for compatibility and I can reboot them
> individually.  I have over 80 VMs, many behind a load balancer (for HA
> and load sharing), but taking them all down will obviously still
> interrupt service for a while.
>
> Is there a safe way around that?
>
> I saw someone mention they partitioned their servers and made a new
> cluster (with the new version), and migrated VMs from cluster to
> cluster.  Can I do live migrations in that case?  How do I get the
> hosted engine from one cluster to another (especially with starting at
> 3.5)?

You'll definitely need hosted-engine downtime, but that's usually not
an issue. For your other VMs, not sure - I think that if you get a mark
saying they should be rebooted, they should. See also:

https://bugzilla.redhat.com/show_bug.cgi?id=1336527

Best,
-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Cluster compatibility version and major upgrades

[Chris Adams]

Hello again, still working on my upgrade from 3.5...

I'm trying to understand the cluster compatibility version setting and
how that applies to major upgrades.  Do I have to always raise the
compatibility version when I do a major upgrade?  In other words, when I
upgrade from 3.5 to 3.6, do I need to raise it to 3.6 before I upgrade
to 4.0 (and then again raise it 4.0 before upgrading to 4.1)?

It looks like the 3.6->4.0 EL6->EL7 migration requires the cluster
compatibility level to be at 3.6 (if I'm reading things right).

It appears that when I upgrade to 3.6, I will have to stop all running
VMs to raise the compatibility version (and I found an open bug about
whether that's possible with the hosted engine).  It sounds like with
4.0, the VMs can be flagged for compatibility and I can reboot them
individually.  I have over 80 VMs, many behind a load balancer (for HA
and load sharing), but taking them all down will obviously still
interrupt service for a while.

Is there a safe way around that?

I saw someone mention they partitioned their servers and made a new
cluster (with the new version), and migrated VMs from cluster to
cluster.  Can I do live migrations in that case?  How do I get the
hosted engine from one cluster to another (especially with starting at
3.5)?

-- 
Chris Adams 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Cluster compatibility

[Dan Kenigsberg]

On Sun, Jan 26, 2014 at 01:38:50PM +0200, Itamar Heim wrote:
 On 01/23/2014 11:54 AM, Sandro Bonazzola wrote:
 Il 23/01/2014 10:49, Piotr Kliczewski ha scritto:
 I wanted to install two hosts one on f19 and the second on el6. I
 created additional cluster for el6.
 Host installation for el6 worked well and it joined the cluster
 without any issues. Whereas host in f19was successfully deployed
 but it failed to join the cluster due to:
 
 Host fedora is compatible with versions (3.0,3.1,3.2,3.3) and cannot
 join Cluster Default which is set to version 3.4.
 
 known issue, on F19 please enable fedora-virt-preview repo, update 
 libvirt* and retry
 
 
 why would a newer libvirt be required to get 3.4 compat mode?

http://gerrit.ovirt.org/#/c/23628/4/vdsm/caps.py


VIR_MIGRATE_ABORT_ON_ERROR not found in libvirt,
support for clusterLevel = 3.4 is disabled.
For Fedora 19 users, please consider upgrading
libvirt from the virt-preview repository

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Cluster compatibility

[Itamar Heim]

On 01/23/2014 11:54 AM, Sandro Bonazzola wrote:

Il 23/01/2014 10:49, Piotr Kliczewski ha scritto:

I wanted to install two hosts one on f19 and the second on el6. I
created additional cluster for el6.
Host installation for el6 worked well and it joined the cluster
without any issues. Whereas host in f19was successfully deployed
but it failed to join the cluster due to:

Host fedora is compatible with versions (3.0,3.1,3.2,3.3) and cannot
join Cluster Default which is set to version 3.4.


known issue, on F19 please enable fedora-virt-preview repo, update libvirt* 
and retry



why would a newer libvirt be required to get 3.4 compat mode?

but you will fail after that as well - if the first host you joined is 
.el6, the emulation mode for VMs is set to -m rhel65, which the fedora 
host is not compatible with. you first need to change the emulation mode 
to 'pc'.


also, expect bugs on live migration between fedora and .el6 hosts - live 
migration is delicate enough.







Here are the versions that I use:

engine:
Name: ovirt-engine
Arch: noarch
Version : 3.4.0
Release : 0.5.beta1.fc19
Size: 1.5 M
Repo: installed
 From repo   : ovirt-3.4.0-prerelease

fedora host:
Name: vdsm
Arch: x86_64
Version : 4.14.1
Release : 2.fc19
Size: 2.9 M
Repo: installed
 From repo   : ovirt-3.4.0-prerelease

el6 host:
Name: vdsm
Arch: x86_64
Version : 4.14.1
Release : 2.el6
Size: 2.9 M
Repo: installed
 From repo   : ovirt-3.4.0-prerelease

Both clusters are set to be compatible with 3.4.

Is there anything that I am missing?

Piotr
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users






___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[Users] Cluster compatibility

[Piotr Kliczewski]

I wanted to install two hosts one on f19 and the second on el6. I
created additional cluster for el6.
Host installation for el6 worked well and it joined the cluster
without any issues. Whereas host in f19was successfully deployed
but it failed to join the cluster due to:

Host fedora is compatible with versions (3.0,3.1,3.2,3.3) and cannot
join Cluster Default which is set to version 3.4.

Here are the versions that I use:

engine:
Name: ovirt-engine
Arch: noarch
Version : 3.4.0
Release : 0.5.beta1.fc19
Size: 1.5 M
Repo: installed
From repo   : ovirt-3.4.0-prerelease

fedora host:
Name: vdsm
Arch: x86_64
Version : 4.14.1
Release : 2.fc19
Size: 2.9 M
Repo: installed
From repo   : ovirt-3.4.0-prerelease

el6 host:
Name: vdsm
Arch: x86_64
Version : 4.14.1
Release : 2.el6
Size: 2.9 M
Repo: installed
From repo   : ovirt-3.4.0-prerelease

Both clusters are set to be compatible with 3.4.

Is there anything that I am missing?

Piotr
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Cluster compatibility

[Sandro Bonazzola]

Il 23/01/2014 10:49, Piotr Kliczewski ha scritto:
 I wanted to install two hosts one on f19 and the second on el6. I
 created additional cluster for el6.
 Host installation for el6 worked well and it joined the cluster
 without any issues. Whereas host in f19was successfully deployed
 but it failed to join the cluster due to:
 
 Host fedora is compatible with versions (3.0,3.1,3.2,3.3) and cannot
 join Cluster Default which is set to version 3.4.

known issue, on F19 please enable fedora-virt-preview repo, update libvirt* 
and retry



 
 Here are the versions that I use:
 
 engine:
 Name: ovirt-engine
 Arch: noarch
 Version : 3.4.0
 Release : 0.5.beta1.fc19
 Size: 1.5 M
 Repo: installed
 From repo   : ovirt-3.4.0-prerelease
 
 fedora host:
 Name: vdsm
 Arch: x86_64
 Version : 4.14.1
 Release : 2.fc19
 Size: 2.9 M
 Repo: installed
 From repo   : ovirt-3.4.0-prerelease
 
 el6 host:
 Name: vdsm
 Arch: x86_64
 Version : 4.14.1
 Release : 2.el6
 Size: 2.9 M
 Repo: installed
 From repo   : ovirt-3.4.0-prerelease
 
 Both clusters are set to be compatible with 3.4.
 
 Is there anything that I am missing?
 
 Piotr
 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users