Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1497925 - [TestOnly] Test and provide a production-quality example of setting up self-hosted engine
[TestOnly] Test and provide a production-quality example of setting up self-h...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup (Show other bugs)
4.1.6
Unspecified Unspecified
high Severity medium
: ovirt-4.2.5
: ---
Assigned To: Nikolai Sednev
Nikolai Sednev
: TestOnly, Triaged, ZStream
Depends On:
Blocks: 1609651
  Show dependency treegraph
 
Reported: 2017-10-03 03:08 EDT by Lucy Bopf
Modified: 2018-07-31 13:50 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-07-31 13:50:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Integration
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:2322 None None None 2018-07-31 13:50 EDT

  None (edit)
Description Lucy Bopf 2017-10-03 03:08:20 EDT
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 10:29:38 EDT
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 02:19:07 EDT
Opened a doc bug; setting doc text flag to -.
Comment 8 errata-xmlrpc 2018-07-31 13:50:41 EDT
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

Note You need to log in before you can comment on or make changes to this bug.