This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9KsRfLQotHnQAC863fMb16EJuLmNKCqpi
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
There is one obvious error in the web UI that I've overlooked so
far. 'Events' lists the following:
'The Hosted Engine Storage Domain doesn't no exist. It should be
imported into the setup.'
Except finding the github link to the source code googling didn't
reveal any hints on what to do to remedy this problem.
Cheers
Richard
On 09/16/2015 03:33 PM, Richard Neuboeck wrote:
Hi oVirt Team,
=20
I'm trying to set up oVirt 3.6 on three virtualization hosts
connected to two other machines solely providing a replica 2 gluster
storage. I know and understand that this setup is basically unwise
and not supported but to prevent the gluster storage from going off
line I followed the suggestion in
https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/Ad=
ministration_Guide/sect-Managing_Split-brain.html
8.10.1.1 and added a dummy node with no bricks. Removing the
requirement for replica 3 in nfs.py and allowing replica count 2 in
vdsm.conf makes the installation possible without error.
=20
But at the first login on the web UI the only thing showing that's
configured during the installation process is the virtualization host.
=20
The Engine VM is not listed in the Virtual Machines tab though the
hosts shows one running VM. After watching several youtube videos
from self hosed engine installations I'm guessing the Engine VM
should be visible. Is there anything I can do?
=20
The Storage tab is completely empty. The ISO Domain that is
configured during the install is not shown. As well as the gluster
storage that is storing the Engine VM.
=20
I've heard in this video from Martin Sivak
https://www.youtube.com/watch?v=3DEbRdUPVlxyQ that the storage domain
where the Engine is stored is hidden. Why is that?
=20
So if the Engine storage is separated from the other VMs storage
there should be two gluster volumes for VM storage if the self
hosted setup is used?
=20
Why is the ISO Domain not shown?
=20
Since I'm (still) an oVirt newbie I'm guessing something has gone
wrong during the installation or I'm missing some piece of the
puzzle. So here are more details:
- The gluster hosts are running an up date CentOS 7.1, Gluster 3.7.
The volume where the Engine is stored has the recommended
optimizations as described in
http://www.ovirt.org/Features/GlusterFS_Storage_Domain
- The self hosted engine deployment install is running on a minimal
CentOS 7.1 (up to date).
http://www.ovirt.org/Hosted_Engine_Howto#Fresh_Install
- The repo from which oVirt is coming:
http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm
- I modified
/usr/share/ovirt-hosted-engine-setup/plugins/ovirt-hosted-engine-setup/=
storage/nfs.py
and substituted the replica 3 requirements appropriately for replica
2
- and added allowed_replica_counts =3D 1,2,3 in /etc/vdsm/vdsm.conf
- hosted-engine --deploy runs without errors. Except for
'balloonInfo' errors vdsm.log doesn't show any (obvious) errors either.=
- The engine setup in the VM (CentOS 7.1 again) runs without
problems as well.
- After the install has finished the Engine is _not_ run
automatically. After waiting some minutes I've started it running
hosted-engine --vm-start.
=20
So far I've wiped everything clean and tried to install oVirt 3.6
twice and twice it was the same result so I'm not sure how to proceed.
=20
Any suggestions on what may have gone wrong or what I've missed to do?
=20
Cheers
Richard
=20
=20
=20
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
=20
--=20
/dev/null
--9KsRfLQotHnQAC863fMb16EJuLmNKCqpi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlX5ciEACgkQnGohgOrO9GHByQCdECimPaDPRNDyCdcedXnVxD6z
hnEAn1eMagzddbO7L6FOJJjYCVo0RN8t
=jHOU
-----END PGP SIGNATURE-----
--9KsRfLQotHnQAC863fMb16EJuLmNKCqpi--