From: "Jiri Moskovcak" <jmoskovc(a)redhat.com&gt; To: "engine-devel" <engine-devel(a)ovirt.org&gt; 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

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

>> 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

>> 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

>> 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…

>> mistake I think the engine should be a bit more clever and not kill itself >

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/i... > >>>> 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(a)redhat.com > Red Hat Czech > RHEV-M SLA / Brno, CZ > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >

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/i... >>> 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(a)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/i... >> >>>>> 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(a)redhat.com >> Red Hat Czech >> RHEV-M SLA / Brno, CZ >> > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)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/i... >>> >>>>>> 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.