[Engine-devel] hosted engine in 3.4
Hi, I was testing the hosted-engine in 3.4 and ran into some troubles, so I'm going to share the results to get some help (or ideas how to fix those problems) Minor: 1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup - I think the setup wizard should be improved to do this workaround automatically 2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen - I found a mallformed fedora-virt-prerelease.repoo file on the installed vm, which might be the cause: https://bugzilla.redhat.com/show_bug.cgi?id=1075963 Major: 1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide... - the host and the engine were installed from the same repo, so I guess the incompatibility was caused by the CPU family, and even if I made the mistake I think the engine should be a bit more clever and not kill itself --Jirka
----- Original Message -----
From: "Jiri Moskovcak" <jmoskovc@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, March 13, 2014 3:27:11 PM Subject: [Engine-devel] hosted engine in 3.4
Hi, I was testing the hosted-engine in 3.4 and ran into some troubles, so I'm going to share the results to get some help (or ideas how to fix those problems)
Minor: 1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
- I think the setup wizard should be improved to do this workaround automatically
Not sure what you refer to - the host? VM? Both? deploy lets you change the MAC for the VM if you want, and also shows you the random MAC it have chosen. Both of these should allow you to config your dhcp/dns server at that point and have the VM automatically get the right ip/hostname during OS installation. Not sure what you mean exactly - we never edit /etc/hosts files, and generally expect a stable dhcp/dns installation. That's true also for a normal engine installation.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
We intend to supply some image (iso/ovf) that will include everything needed. Not sure when this will be ready. For the time being, you do everything by yourself - install the OS, add repos, install and setup the engine, etc. Note that you can choose network boot and make everything automated.
- I found a mallformed fedora-virt-prerelease.repoo file on the installed vm, which might be the cause: https://bugzilla.redhat.com/show_bug.cgi?id=1075963
Major: 1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide...
- the host and the engine were installed from the same repo, so I guess the incompatibility was caused by the CPU family, and even if I made the
That's probably because you have a problem with the repo (as pointed above) and install different versions on the host and VM.
mistake I think the engine should be a bit more clever and not kill itself
I might agree here, but generally this should not happen. You are of course more than welcome to open bugs where relevant! -- Didi
On 03/13/2014 02:54 PM, Yedidyah Bar David wrote:
----- Original Message -----
From: "Jiri Moskovcak" <jmoskovc@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, March 13, 2014 3:27:11 PM Subject: [Engine-devel] hosted engine in 3.4
Hi, I was testing the hosted-engine in 3.4 and ran into some troubles, so I'm going to share the results to get some help (or ideas how to fix those problems)
Minor: 1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
- I think the setup wizard should be improved to do this workaround automatically
Not sure what you refer to - the host? VM? Both?
deploy lets you change the MAC for the VM if you want, and also shows you the random MAC it have chosen. Both of these should allow you to config your dhcp/dns server at that point and have the VM automatically get the right ip/hostname during OS installation.
Not sure what you mean exactly - we never edit /etc/hosts files, and generally expect a stable dhcp/dns installation. That's true also for a normal engine installation.
- the VM, I was in the situation where I didn't have the chance to change the dhcp config at the time when I was installing the VM, so the only way for me was to change the /etc/hosts to cheat the setup wizard
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
We intend to supply some image (iso/ovf) that will include everything needed. Not sure when this will be ready. For the time being, you do everything by yourself - install the OS, add repos, install and setup the engine, etc. Note that you can choose network boot and make everything automated.
- I'm talking about the engine install inside the VM. I have the VM with the os, so the hosted-engine-setup can ask for the root password and simply install all the packages and configure the engine (I don't consider this a bug more like a idea for improvements)
- I found a mallformed fedora-virt-prerelease.repoo file on the installed vm, which might be the cause: https://bugzilla.redhat.com/show_bug.cgi?id=1075963
Major: 1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide...
- the host and the engine were installed from the same repo, so I guess the incompatibility was caused by the CPU family, and even if I made the
That's probably because you have a problem with the repo (as pointed above) and install different versions on the host and VM.
- no, when I found the broken repo file I've fixed it to use the same as the host and only after that I've installed the engine
mistake I think the engine should be a bit more clever and not kill itself
I might agree here, but generally this should not happen.
You are of course more than welcome to open bugs where relevant!
I will, just want to try that once more, to get more details. Thanks, Jirka
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :) Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on.. [1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports. If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
mistake I think the engine should be a bit more clever and not kill itself
I think it is the VDSM that does the actual killing :) But overall I agree, the setup is too fragile and I encountered all of the issues when installing hosted engine for the first time too. -- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
Il 14/03/2014 10:13, Martin Sivak ha scritto:
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
Ohad is preparing an OVA for allowing a quick setup. But feel free to open a RFE for the kickstart solution as well.
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
mistake I think the engine should be a bit more clever and not kill itself
I think it is the VDSM that does the actual killing :)
But overall I agree, the setup is too fragile and I encountered all of the issues when installing hosted engine for the first time too.
Please be sure to have a BZ for each issue you encountered. We'll try to address them.
-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 03/14/2014 10:17 AM, Sandro Bonazzola wrote:
Il 14/03/2014 10:13, Martin Sivak ha scritto:
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
Ohad is preparing an OVA for allowing a quick setup. But feel free to open a RFE for the kickstart solution as well.
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
mistake I think the engine should be a bit more clever and not kill itself
I think it is the VDSM that does the actual killing :)
But overall I agree, the setup is too fragile and I encountered all of the issues when installing hosted engine for the first time too.
Please be sure to have a BZ for each issue you encountered. We'll try to address them.
Sure, I'm about to create them, btw, I'm a new developer assigned to the hosted-engine so I'll be probably fixing those issues with you :) --Jirka
-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Il 14/03/2014 10:22, Jiri Moskovcak ha scritto:
On 03/14/2014 10:17 AM, Sandro Bonazzola wrote:
Il 14/03/2014 10:13, Martin Sivak ha scritto:
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
Ohad is preparing an OVA for allowing a quick setup. But feel free to open a RFE for the kickstart solution as well.
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
mistake I think the engine should be a bit more clever and not kill itself
I think it is the VDSM that does the actual killing :)
But overall I agree, the setup is too fragile and I encountered all of the issues when installing hosted engine for the first time too.
Please be sure to have a BZ for each issue you encountered. We'll try to address them.
Sure, I'm about to create them, btw, I'm a new developer assigned to the hosted-engine so I'll be probably fixing those issues with you :)
welcome aboard :-)
--Jirka
-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 03/14/2014 10:13 AM, Martin Sivak wrote:
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
vdsm version on the host: vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease ovirt-engine installed in the VM: ovirt-engine-3.4.0-0.13.rc.fc19.noarch - and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set to version 3.4" and commits suicide ... - I'm going to create the bz now
mistake I think the engine should be a bit more clever and not kill itself
I think it is the VDSM that does the actual killing :)
- but the engine tells the vdsm to stop the vds, doesn't it?
But overall I agree, the setup is too fragile and I encountered all of the issues when installing hosted engine for the first time too.
-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
On 03/14/2014 10:13 AM, Martin Sivak wrote:
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
vdsm version on the host: vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
ovirt-engine installed in the VM: ovirt-engine-3.4.0-0.13.rc.fc19.noarch
- and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set to version 3.4"
Above is probably due to libvirt not updated to latest from fedora-virt-preview repo. Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package? If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure on libvirt people for having them pushing the newest package into Fedora. Thoughts?
and commits suicide ...
- I'm going to create the bz now
mistake I think the engine should be a bit more clever and not kill itself
I think it is the VDSM that does the actual killing :)
- but the engine tells the vdsm to stop the vds, doesn't it?
But overall I agree, the setup is too fragile and I encountered all of the issues when installing hosted engine for the first time too.
-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 03/14/2014 10:46 AM, Sandro Bonazzola wrote:
Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
On 03/14/2014 10:13 AM, Martin Sivak wrote:
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
vdsm version on the host: vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
ovirt-engine installed in the VM: ovirt-engine-3.4.0-0.13.rc.fc19.noarch
- and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set to version 3.4"
Above is probably due to libvirt not updated to latest from fedora-virt-preview repo. Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package? If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure on libvirt people for having them pushing the newest package into Fedora. Thoughts?
- yes, that might be the case, there is no libvirt in the rc2 repo[1] I used to install the host [1] http://resources.ovirt.org/releases/3.4.0-rc2/rpm/Fedora/19/x86_64/
and commits suicide ...
- I'm going to create the bz now
mistake I think the engine should be a bit more clever and not kill itself
I think it is the VDSM that does the actual killing :)
- but the engine tells the vdsm to stop the vds, doesn't it?
But overall I agree, the setup is too fragile and I encountered all of the issues when installing hosted engine for the first time too.
-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Fri, Mar 14, 2014 at 10:46:00AM +0100, Sandro Bonazzola wrote:
Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
On 03/14/2014 10:13 AM, Martin Sivak wrote:
Hi,
1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
vdsm version on the host: vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
ovirt-engine installed in the VM: ovirt-engine-3.4.0-0.13.rc.fc19.noarch
- and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set to version 3.4"
Above is probably due to libvirt not updated to latest from fedora-virt-preview repo. Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package? If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure on libvirt people for having them pushing the newest package into Fedora. Thoughts?
The problem is that F19's libvirt lacks VIR_MIGRATE_ABORT_ON_ERROR (http://gerrit.ovirt.org/#/c/23273/) which is required by clusterLevel 3.4. We found it quite rude for a vdsm upgrade in Fedora 19 to require a version of libvirt that is not on that platform, particularly since the existing version is perfectly usable for clusterLevel 3.3. I do not believe we should ship libvirt within oVirt. It is a pain to mainatain (and issue bugfixes, and worry about security hotfixes). A prefereable approach would be to have ovirt-release.f19.rpm link to the relevant virt-preview repository.
Il 20/03/2014 12:00, Dan Kenigsberg ha scritto:
On Fri, Mar 14, 2014 at 10:46:00AM +0100, Sandro Bonazzola wrote:
Il 14/03/2014 10:39, Jiri Moskovcak ha scritto:
On 03/14/2014 10:13 AM, Martin Sivak wrote:
Hi,
> 1. You need to have some MAC address with static ip and FQDN, otherwise > you have to change /etc/hosts at least for the first part of the setup
I believe you were there when we were discussing this with pstehlik :)
Btw in this case you have to change /etc/hosts on all hosts and inside the engine VM.
> 2. When the VM install is complete I would expect the setup wizard to > install the engine to the VM automatically - which at least in my case - > doesn't happen
I also proposed kickstart based setup to Sandro. You would give a repo to setup and it would download the kernel/initrd from it [1] and create a kickstart with the right root password, engine setup and so on..
[1] http://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Fedora/x86_64/os/imag...
> 1. once I managed to install the engine to the vm it tried to add the > host it was running on to the engine and it failed with a message "Host > compatibility version doesn't match the cluster compatibility version", > and then it marked the host as non operational which killed the vm with > the engine, so the engine actually committed suicide…
Check your VDSM version. Especially the content of /usr/share/vdsm/dsaversion.py file. There are couple of lists specifying the cluster and engine versions that the VDSM supports.
If you use 3.4 engine it needs 3.4 VDSM as well.. and the prerelease repo is not enabled by default.
vdsm version on the host: vdsm-4.14.5-0.fc19.x86_64 @ovirt-3.4.0-prerelease
ovirt-engine installed in the VM: ovirt-engine-3.4.0-0.13.rc.fc19.noarch
- and it dies with the error message: "Host hosted_engine_1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set to version 3.4"
Above is probably due to libvirt not updated to latest from fedora-virt-preview repo. Dan, Yaniv, any reason for not explicitly requiring the updated version of libvirt in VDSM package? If it's just because libvirt is not yet in official Fedora repository, maybe we should ship it on ovirt repository until it's in and put some pressure on libvirt people for having them pushing the newest package into Fedora. Thoughts?
The problem is that F19's libvirt lacks VIR_MIGRATE_ABORT_ON_ERROR (http://gerrit.ovirt.org/#/c/23273/) which is required by clusterLevel 3.4.
We found it quite rude for a vdsm upgrade in Fedora 19 to require a version of libvirt that is not on that platform, particularly since the existing version is perfectly usable for clusterLevel 3.3.
I do not believe we should ship libvirt within oVirt. It is a pain to mainatain (and issue bugfixes, and worry about security hotfixes). A prefereable approach would be to have ovirt-release.f19.rpm link to the relevant virt-preview repository.
Any chance of having new libvirt ported to f19 main repository?
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
Il 13/03/2014 14:27, Jiri Moskovcak ha scritto:
Hi, I was testing the hosted-engine in 3.4 and ran into some troubles, so I'm going to share the results to get some help (or ideas how to fix those problems)
Hi, thanks for testing Hosted Engine
Minor: 1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup
- I think the setup wizard should be improved to do this workaround automatically
Well, you can have DHCP and DNS configured before starting the deploy process and assign the MAC address to the VM you're going to create for getting the right IP and avoid to use /etc/hosts. But yes, otherwise you need to use static IPs and configure /etc/hosts accordingly.
2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen
No, it's a manual step, there's no automation for doing that yet.
- I found a mallformed fedora-virt-prerelease.repoo file on the installed vm, which might be the cause: https://bugzilla.redhat.com/show_bug.cgi?id=1075963
Can't reproduce the issue, closed as works for me, please reopen it if you can provide a sequence for reproducing it.
Major: 1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide...
this is indeed due to malformed fedora-virt-prerelease.repoo. You had VDSM running in 3.3 compatibility mode because you're missing latest libvirt while the engine is running a cluster in 3.4 compatibility mode.
- the host and the engine were installed from the same repo, so I guess the incompatibility was caused by the CPU family, and even if I made the mistake I think the engine should be a bit more clever and not kill itself
I think that we can add a check on vdsm compatibility level and create the engine cluster with the same level, not assuming that people are running latest libvirt. BTW I'm not sure about implications in running Hosted Engine in 3.3 compatibility mode. CCing VDSM people.
--Jirka
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (5)
-
Dan Kenigsberg -
Jiri Moskovcak -
Martin Sivak -
Sandro Bonazzola -
Yedidyah Bar David