Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1497925

Summary:	[TestOnly] Test and provide a production-quality example of setting up self-hosted engine
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Lucy Bopf <lbopf>
Component:	ovirt-hosted-engine-setup	Assignee:	Nikolai Sednev <nsednev>
Status:	CLOSED ERRATA	QA Contact:	Nikolai Sednev <nsednev>
Severity:	medium	Docs Contact:
Priority:	high
Version:	4.1.6	CC:	lbopf, lsurette, stirabos, trichard, ylavi
Target Milestone:	ovirt-4.2.5	Keywords:	TestOnly, Triaged, ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-31 17:50:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1609651

Description Lucy Bopf 2017-10-03 07:08:20 UTC

In bug 1493020, Yaniv Kaul noted that the documentation was lacking some specific networking information, and suggested that a production-quality example of setting up self-hosted engine be considered.

Such an example could eventually be added to the documentation, but it first needs to be defined by PM, outlined, and tested. To allow this activity to be considered and then scheduled, I am raising this bug against a self-hosted engine engineering component. If this work goes ahead, a dependent documentation bug can be raised at the time of the handover to the documentation team.

Comment 5 Nikolai Sednev 2018-07-08 14:29:38 UTC

Forth to our latest conversation with Yaniv and as we agreed, I'm providing my recommendations:
IMHO

We should recommend to have stable network infrastructure and storage environment, properly designed by network professionals, with properly configured DNS and DHCP records, prior to any SHE deployments.

For HA to work properly, LAG/Bond/Ether-channel should be used for layer two (L2) link failures and network congestions, for redundancy customers should use pair of NICs on hosts, such design will eliminate single NIC failure on host's level.

Storage connectivity should use either multiple dedicated NICs to work in separate network as multi-path or at least to operate in multiple storage-dedicated VLANs over shared or dedicated Bond/LAG/Ether-channel, if Bond will be shared with other network traffic, then proper QOS is required for storage and other network traffic. FC should have either two HBAs or at least one dual HBA for L2 link fail over protection.

Ether-channel/Bond/LAG is meant for link failure protection at L2 level only and for providing greater throughput, while single physical link is insufficient and aggregation of multiple physical links in to one logical link is required.

On storage side we should also recommend to have either several Ethernet connections or single/multiple ether-channels, for redundancy and greater throughput.

Comment 6 Tahlia Richardson 2018-07-30 06:19:07 UTC

Opened a doc bug; setting doc text flag to -.

Comment 8 errata-xmlrpc 2018-07-31 17:50:41 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:2322