On Sat, Aug 22, 2020 at 6:26 PM Michael Jones <m...@mikejonesey.co.uk> wrote: > > On 20/08/2020 20:55, Michael Jones wrote: > > On 19/08/2020 14:48, Michael Jones wrote: > > On 19/08/2020 12:12, Michael Jones wrote: > > On 19/08/2020 10:41, Nir Soffer wrote: > > There is no warning the method was deprecated and will be missing > functionality. > > The steps detailed on the alt install page are for the all-in-one running > engine-setup. > > It's also worth noting this works fine in; > > Version 4.3.1.1-1.el7 > > but not in; > > Version 4.4.1.10-1.el8 > > (el8 has the change in imageio daemons) > > The alternate install method is still useful to have, but i think a red > warning about all-in-one on el8 on that page would be good. > > Kind Regards, > Michael Jones > > Micheal, can you file a bug for this? > > If you have a good use case for all-in-one deployment (not using > hosted engine), please explain > it in the bug. > > Personally I think simple all-in-one deployment without the complexity > of hosted engine is better, > and we should keep it, but for this we need to teach engine to handle > the case when the proxy > and the daemon are the same server. > > In this case engine will not try to setup a proxy ticket, and image > transfer would work directly > with the host daemon. > > I'm not very optimistic that we will support this again, since this > feature is not needed for RHV > customers, but for oVirt this makes sense. > > Nir > > Yes, I can file a bug, > > The main usage / setup's I have are; > > on-prem installs: > > - hosted engine > - gluster > - high availiblity > - internal ip address > - easy great... > > dedicated host provider for example OVH single machine: > > - alternate install > - all-in-one > > The main reason for the separation is that using the cockpit install / hosted > engine install causes problems with ip allocations; > > cockpit method requires 1x ip for host, and 1x ip for engine vm, and both ip > must be in the same subnet... > > applying internal ip would cut off access, and to make it even harder, > getting public ip blocks didn't work as the box main ip wouldn't be in the > same subnet, adding nic alias ip doesn't work either (fail on install due to > failing to setup ovirtmgmt network). > > atm, i'll struggle with changing the machine's main ip to be one of the same > subnet with the engine one... (currently causes host to be taken offline due > to hosting provider, health checks) > > provided i can change the host primary ip to be one of the OVH failover ip > allocated in a block... i will be able to install using the cockpit. > > and after the install i can setup internal ip with the network tag. > > Kind Regards, > > Mike > > despite managing to get OVH to disable monitoring (ping to the main ip, and > rebooting host) and getting the host in the same ip range as the engine vm... > > ie: > > host ip: 158.x.x.13/32 = not used anymore > > new subnet: 54.x.x.x/28 > > and reserving; > host = 54.x.x.16 > engine = 54.x.x.17 > > [ ERROR ] The Engine VM (54.x.x.17/28) and the default gateway (158.x.x.254) > will not be in the same IP subnet. > > the hosted engine installer crashes due to the gw being in a different > subnet, so all three; > > - host > - engine > - gateway > > must be in the same subnet... > > this rules out an install on ovh dedicated server. > > unless... I can install the all-in-one again (this bit works), and then > install the engine vm in an existing all-in-one setup... > > essentially the cockpit installation is not compatible with this infra setup. > > After going through the documentation again, I understand the best way to > approach this would be to have a remote manager, ie; > > self hosted engine (on-prem) > host/2nd DC/Cluster (remote/ovh) > > standalone manager (on-prem) > host/2nd DC/Cluster (remote/ovh) > > That way resolves the ip issues (only need host ip, just don't install the > manager on the remote server) > > outstanding... i need to workout the security implications of this. > > shame all-in-one is gone, but the above does work, and even means the remote > host can again use local storage. > > I'll raise the bug report now i've finished testing, as I think stand alone, > all-in-one, dedicated hosts are affordable and open ovirt to a wider user > base (keeping hardware requirements minimal). > > Thanks again, > > Mike > > Bug raised: > > https://bugzilla.redhat.com/show_bug.cgi?id=1871348
Thanks, but we need more info why you cannot use the recommended deployment. See my questions in the bug. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2TGH3E4MZWFKIQGID64MDRBHYMHT3USZ/
