Re: [Users] Host can't join the cluster
On 05/19/2012 05:54 PM, Itamar Heim wrote: On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: On 05/17/2012 02:11 PM, Omer Frenkel wrote: ... 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 indeed. and code seems to be correct for that flow. either engine has support for vdsm version. or vdsm reports it supports this engine version. so danken - i think the missing part is actually vdsm telling engine 3.1 version is supported: in ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], (and yes, need to change this to supportedEngine naming, but i suggest doing this in a separate patch for engine to do this with backward compatibility) I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I think that if vdsm reports that it supports clusterLevel 3.1, Engine should believe vdsm. supportedRHEVMs was intended as a hack to allow new vdsms tell old Engines that they are fine. That should not be the main path of fixing the issue. I think there was some concept of distinguishing between supported compatibility levels vs. supported versions of engine with that compatibility level if engine did not specify it supports that vdsm version (i.e., tested and supported vs. we just think this should work) Itamar - this is true. The misleading error occurs as at engine code we use the same message for both cases. We can separate to having two error messages: a. Incompatible cluster level b. VDSM version not supported. However, if we use this, it means that after every release of VDSM, we should update the SupportedVDSMVersions (i.e - add 4.9.6 to it) Is this what we want to do? The other option -as previously mentioned is to rely only on cluster compatibility level comparison (using the 'supprtedRHEVMs' reported by VDSM) Thoughts about this are more than welcome Yair ___ 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: [Users] Host can't join the cluster
On 05/21/2012 04:55 PM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Itamar Heim ih...@redhat.com Cc: users@ovirt.org Sent: Monday, May 21, 2012 4:46:20 PM Subject: Re: [Users] Host can't join the cluster On 05/19/2012 05:54 PM, Itamar Heim wrote: On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: On 05/17/2012 02:11 PM, Omer Frenkel wrote: ... 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 indeed. and code seems to be correct for that flow. either engine has support for vdsm version. or vdsm reports it supports this engine version. so danken - i think the missing part is actually vdsm telling engine 3.1 version is supported: in ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], (and yes, need to change this to supportedEngine naming, but i suggest doing this in a separate patch for engine to do this with backward compatibility) I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I think that if vdsm reports that it supports clusterLevel 3.1, Engine should believe vdsm. supportedRHEVMs was intended as a hack to allow new vdsms tell old Engines that they are fine. That should not be the main path of fixing the issue. I think there was some concept of distinguishing between supported compatibility levels vs. supported versions of engine with that compatibility level if engine did not specify it supports that vdsm version (i.e., tested and supported vs. we just think this should work) Itamar - this is true. The misleading error occurs as at engine code we use the same message for both cases. We can separate to having two error messages: a. Incompatible cluster level b. VDSM version not supported. However, if we use this, it means that after every release of VDSM, we should update the SupportedVDSMVersions (i.e - add 4.9.6 to it) Is this what we want to do? The other option -as previously mentioned is to rely only on cluster compatibility level comparison (using the 'supprtedRHEVMs' reported by VDSM) Thoughts about this are more than welcome Yair i agree with this approach, just one fix, we should use vdsm's 'supportedProtocols' which match the engine's cluster levels. this way the versions of the software are not important, only what 'protocols' (or cluster levels) are supported in both. Exactly, my bad. Thanks for the correction! ___ 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 mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
On Mon, May 21, 2012 at 09:55:11AM -0400, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Itamar Heim ih...@redhat.com Cc: users@ovirt.org Sent: Monday, May 21, 2012 4:46:20 PM Subject: Re: [Users] Host can't join the cluster On 05/19/2012 05:54 PM, Itamar Heim wrote: On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: On 05/17/2012 02:11 PM, Omer Frenkel wrote: ... 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 indeed. and code seems to be correct for that flow. either engine has support for vdsm version. or vdsm reports it supports this engine version. so danken - i think the missing part is actually vdsm telling engine 3.1 version is supported: in ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], (and yes, need to change this to supportedEngine naming, but i suggest doing this in a separate patch for engine to do this with backward compatibility) I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I think that if vdsm reports that it supports clusterLevel 3.1, Engine should believe vdsm. supportedRHEVMs was intended as a hack to allow new vdsms tell old Engines that they are fine. That should not be the main path of fixing the issue. I think there was some concept of distinguishing between supported compatibility levels vs. supported versions of engine with that compatibility level if engine did not specify it supports that vdsm version (i.e., tested and supported vs. we just think this should work) Itamar - this is true. The misleading error occurs as at engine code we use the same message for both cases. We can separate to having two error messages: a. Incompatible cluster level b. VDSM version not supported. However, if we use this, it means that after every release of VDSM, we should update the SupportedVDSMVersions (i.e - add 4.9.6 to it) Is this what we want to do? The other option -as previously mentioned is to rely only on cluster compatibility level comparison (using the 'supprtedRHEVMs' reported by VDSM) Thoughts about this are more than welcome Yair i agree with this approach, just one fix, we should use vdsm's 'supportedProtocols' which match the engine's cluster levels. this way the versions of the software are not important, only what 'protocols' (or cluster levels) are supported in both. Is supportedProtocols ever used by Engine now? I think it is stale. I resent introducing it, as the logic is too complex as it is. I think it is enough to have a set of SupportedVDSMVersions, with the extra ability to ship a vdsm with another version, reporting its supportedeRHEVMs. It is unlikely that vdsm is ever shipped without a change to the protocol (we are not in the business of reimplementation of old APIs). So supportedProtocols is not going to change any slower than vdsm version. Please add vdsm-4.9.6 to the set of SupportedVDSMVersions. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
On 05/18/2012 04:20 PM, Dan Kenigsberg wrote: On Thu, May 17, 2012 at 10:03:31PM +0300, Itamar Heim wrote: On 05/17/2012 02:11 PM, Omer Frenkel wrote: ... 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 indeed. and code seems to be correct for that flow. either engine has support for vdsm version. or vdsm reports it supports this engine version. so danken - i think the missing part is actually vdsm telling engine 3.1 version is supported: in ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], (and yes, need to change this to supportedEngine naming, but i suggest doing this in a separate patch for engine to do this with backward compatibility) I do not mind adding 3.1 to supportedRHEVMs on vdsm side, but I think that if vdsm reports that it supports clusterLevel 3.1, Engine should believe vdsm. supportedRHEVMs was intended as a hack to allow new vdsms tell old Engines that they are fine. That should not be the main path of fixing the issue. I think there was some concept of distinguishing between supported compatibility levels vs. supported versions of engine with that compatibility level if engine did not specify it supports that vdsm version (i.e., tested and supported vs. we just think this should work) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
- Original Message - From: Itamar Heim ih...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: Haim Ateya hat...@redhat.com, users@ovirt.org, Omer Frenkel ofren...@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. 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: ov...@qip.ru To: Haim Ateyahat...@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 Ateyahat...@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
On 05/17/2012 11:28 AM, Omer Frenkel wrote: - Original Message - From: Itamar Heimih...@redhat.com To: Dan Kenigsbergdan...@redhat.com Cc: Haim Ateyahat...@redhat.com, users@ovirt.org, Omer Frenkelofren...@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). 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? 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: ov...@qip.ru To: Haim Ateyahat...@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 Ateyahat...@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
- Original Message - From: Itamar Heim ih...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: Haim Ateya hat...@redhat.com, users@ovirt.org, Dan Kenigsberg dan...@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 Heimih...@redhat.com To: Dan Kenigsbergdan...@redhat.com Cc: Haim Ateyahat...@redhat.com, users@ovirt.org, Omer Frenkelofren...@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: ov...@qip.ru To: Haim Ateyahat...@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 Ateyahat...@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Host can't join the cluster
On 05/17/2012 02:11 PM, Omer Frenkel wrote: ... 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 indeed. and code seems to be correct for that flow. either engine has support for vdsm version. or vdsm reports it supports this engine version. so danken - i think the missing part is actually vdsm telling engine 3.1 version is supported: in ./vdsm/dsaversion.py.in:'supportedRHEVMs': ['3.0'], (and yes, need to change this to supportedEngine naming, but i suggest doing this in a separate patch for engine to do this with backward compatibility) 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: ov...@qip.ru To: Haim Ateyahat...@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 Ateyahat...@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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:04Host 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:04Detected new Host kvm04. Host state was set to Up.2012-May-16, 16:05:03Host kvm04 was autorecovered.2012-May-16, 16:05:03Host 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:02Host 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 написал: 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. Thanks, Haim From: ov...@qip.ru To: users@ovirt.org Sent: Wednesday, May 16, 2012 1:58:33 PM Subject: [Users] Host can't join the cluster After upgrade of vdsm from 4.9.6-0.196.gitb8b79b5 to 4.9.6-0.201.git98e8078 engine set host in nonoperational mode, the error is Host kvm04 is compatible with versions (3.0,3.1) and cannot join Cluster Default which is set to version 3.1. -- ___ 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: [Users] Host can't join the cluster
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: ov...@qip.ru To: Haim Ateya hat...@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 hat...@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. Thanks, Haim From: ov...@qip.ru To: users@ovirt.org Sent: Wednesday, May 16, 2012 1:58:33 PM Subject: [Users] Host can't join the cluster After upgrade of vdsm from 4.9.6-0.196.gitb8b79b5 to 4.9.6-0.201.git98e8078 engine set host in nonoperational mode, the error is Host kvm04 is compatible with versions (3.0,3.1) and cannot join Cluster Default which is set to version 3.1. -- ___ 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: [Users] Host can't join the cluster
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. 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: ov...@qip.ru To: Haim Ateya hat...@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 hat...@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
