----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com> Cc: "Haim Ateya" <hateya@redhat.com>, users@ovirt.org, "Dan Kenigsberg" <danken@redhat.com> Sent: Thursday, May 17, 2012 11:30:34 AM Subject: Re: [Users] Host can't join the cluster
On 05/17/2012 11:28 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Dan Kenigsberg"<danken@redhat.com> Cc: "Haim Ateya"<hateya@redhat.com>, users@ovirt.org, "Omer Frenkel"<ofrenkel@redhat.com> Sent: Wednesday, May 16, 2012 8:50:59 PM Subject: Re: [Users] Host can't join the cluster
On 05/16/2012 05:51 PM, Dan Kenigsberg wrote:
How difficult would it be for Engine to handle the true version-release of vdsm?
As a stop-gap measure, Engine could convert the reported version-release into the floating point numbers it can handle. The same stop-gap could be done on Vdsm side, but I consider this as a step backward.
why does engine cares about vdsm version, rather than compatibility levels reported by vdsm?
the definition was, as i remember: vdsm reports which engine (cluster levels) it supports. engine reports which vdsm versions it supports. both must apply so a host would be active.
well, first, then the error message is wrong and misleading (complains a vdsm with compat levels of (3.0,3.1) can't join the cluster which is 3.1).
i agree
second, iirc, the definition was vdsm can override engine vdsm version check, so a newer vdsm could still report it will work with an older engine, without needing to change the older engine to match it?
i agree as well, i think the intention was for newer builds in the same version, so revision can be changed, but major version should be coordinated with the engine. maybe the logic can changed just to make sure there is a match between supported cluster levels in vdsm and engine and ignore engine / vdsm software versions
On Wed, May 16, 2012 at 09:59:42AM -0400, Haim Ateya wrote:
This issue was introduced in Ic7b4a63a974bfc301f3294603d8fe91f534b74dd (http://gerrit.ovirt.org/4284), we are currently working to resolve this issue and patch will be sent soon. meantime, you can edit /usr/share/vdsm/dsaversion.py and change the following fields:
software_version = "4.9" software_revision = "0
restart vdsmd service and activate host again.
Haim ----- Original Message -----
From: ovirt@qip.ru To: "Haim Ateya"<hateya@redhat.com> Cc: users@ovirt.org Sent: Wednesday, May 16, 2012 3:19:04 PM Subject: Re: Re: [Users] Host can't join the cluster
in secure and non secure connections i have the same nonoperational status
the output of getVdsCaps on host is empty
this is event log in webadmin
2012-May-16, 16:05:04
Host kvm04 is compatible with versions (3.0,3.1) and cannot join Cluster Default which is set to version 3.1.
2012-May-16, 16:05:04
Detected new Host kvm04. Host state was set to Up.
2012-May-16, 16:05:03
Host kvm04 was autorecovered.
2012-May-16, 16:05:03
Host kvm04 is compatible with versions (3.0,3.1) and cannot join Cluster Default which is set to version 3.1.
2012-May-16, 16:01:02
Host kvm04 was activated by admin@internal. if i do downgrade to 4.9.6-0.196.gitb8b79b5 host state set's to Up.
Срд 16 Май 2012 15:24:36 +0400, Haim Ateya<hateya@redhat.com> написал:
> I guess you compiled vdsm yourself, please run the following > command > from your host:
> vdsClient -s 0 getVdsCaps (assuming you work with SSL).
> anyhow, it smells like a known issue with latest build where > vdsm > returns supported_clusters = 3.0 and engine reject host, but > lets > find out.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users