10:27 a.m.
Hello,
between problems solved in upcoming 4.1.3 release I see this:
Lost Connection After Host Deploy when 4.1.3 Host Added to 4.1.2 Engine
tracked by
https://bugzilla.redhat.com/show_bug.cgi?id=1459484
As a matter of principle I would prefer to force that an engine version
must be greater or equal than all the hosts it is intended to manage.
I don't find safe to allow this and probably unnecessary maintenance
work... what do you think?
For example if you go here:
http://www.vmware.com/resources/compatibility/sim/interop_matrix.php#inte...
you can see that:
- a vCenter Server 5.0U3 cannot manage an ESXi 5.1 host
- a vCenter Server 5.1U3 cannot manage an ESXi 6.0 host
- a vCenter Server 6.0U3 cannot manage an ESXi 6.5 host
In my opinion an administrator of the virtual infrastructure doesn't expect
to be able to manage newer versions' hosts with older engines... and
probably he/she doesn't feel this feature as a value added.
Just my thoughts.
Cheers,
Gianluca
10:31 a.m.
On Fri, Jun 16, 2017 at 5:27 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
Hello,
between problems solved in upcoming 4.1.3 release I see this:
Lost Connection After Host Deploy when 4.1.3 Host Added to 4.1.2 Engine
tracked by
https://bugzilla.redhat.com/show_bug.cgi?id=1459484
As a matter of principle I would prefer to force that an engine version
must be greater or equal than all the hosts it is intended to manage.
I don't find safe to allow this and probably unnecessary maintenance
work... what do you think?
For example if you go here:
http://www.vmware.com/resources/compatibility/sim/
interop_matrix.php#interop&1=&2=
you can see that:
- a vCenter Server 5.0U3 cannot manage an ESXi 5.1 host
- a vCenter Server 5.1U3 cannot manage an ESXi 6.0 host
- a vCenter Server 6.0U3 cannot manage an ESXi 6.5 host
In my opinion an administrator of the virtual infrastructure doesn't
expect to be able to manage newer versions' hosts with older engines... and
probably he/she doesn't feel this feature as a value added.
Just my thoughts.
Cheers,
Gianluca
Watching better, VMware supports greater minor versions through a
release... such as vCenter Server 5.1U1 is able to manage 5.1U3 ESXi
hosts.... that is the oVirt case here 4.1.2 vs 4.1.3 hosts...
Sorry
3:07 p.m.
On Fri, Jun 16, 2017 at 6:27 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
Hello,
between problems solved in upcoming 4.1.3 release I see this:
Lost Connection After Host Deploy when 4.1.3 Host Added to 4.1.2 Engine
tracked by
https://bugzilla.redhat.com/show_bug.cgi?id=1459484
I *think* the specific bug was discovered (and fixed) while developing
4.1.3.
As a matter of principle I would prefer to force that an engine version
must be greater or equal than all the hosts it is intended to manage.
I don't find safe to allow this and probably unnecessary maintenance
work... what do you think?
For example if you go here:
http://www.vmware.com/resources/compatibility/sim/
interop_matrix.php#interop&1=&2=
you can see that:
- a vCenter Server 5.0U3 cannot manage an ESXi 5.1 host
- a vCenter Server 5.1U3 cannot manage an ESXi 6.0 host
- a vCenter Server 6.0U3 cannot manage an ESXi 6.5 host
We are more flexible ;-)
While I think it's a matter of taste, I think there are merits to upgrading
the hosts first. For example, assuming you have many hosts, to me it makes
sense to upgrade just one, see that things work well. Then, upgrade
another, perform live migration, etc, see that it's smooth, before
upgrading the manager, which is a bigger task sometimes (rollback is more
challenging, for example, it has a downtime requirements where as single
host maintenance is not requiring the same level of downtime, etc.).
In addition, there are host-based features (VDSM hooks) which do not
mandate a manager upgrade.
In my opinion an administrator of the virtual infrastructure
doesn't
expect to be able to manage newer versions' hosts with older engines... and
probably he/she doesn't feel this feature as a value added.
I'm on your side on this, as I believe the manager should always be the
most up-to-date, but I know others have different opinions and we'd like to
keep it that way.
Y.
Just my thoughts.
Cheers,
Gianluca
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
2719
days inactive
2719
days old
2 comments
2 participants
participants (2)
-
Gianluca Cecchi -
Yaniv Kaul