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 There was also a comment that vprotect shouldn't be using the proxy, I'll check that and raise a separate bug with them. Kind Regards, Mike
_______________________________________________ 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/QYH3MITMZ3474O7VS7OZCK64C6ATMFF3/
