Bug 1558102

Summary: [Docs][Install] Add Info message for boot from SAN for hosts
Product: Red Hat Enterprise Virtualization Manager Reporter: Marina Kalinin <mkalinin>
Component: DocumentationAssignee: Avital Pinnick <apinnick>
Status: CLOSED CURRENTRELEASE QA Contact: Megan Lewis <melewis>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.1.9CC: apinnick, bmarzins, fkust, lsurette, mkalinin, nsoffer, pkovar, srevivo
Target Milestone: ovirt-4.2.6Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: docs-accepted
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-28 06:21:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Docs RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1435335    
Bug Blocks:    

Description Marina Kalinin 2018-03-19 15:54:21 UTC
Based on bz#1435335, we should add a section in RHV install guide for hosts (both RHEL and RHVH), to mention that if booting from SAN, the boot LUN should have a different config than the rest of the LUNs that are visible to the host and are served for RHV storage domain.

Once bz#1435335 is released, we should suggest blacklisting that LUN on vdsm side.

Comment 1 Marina Kalinin 2018-03-19 16:49:04 UTC
Until bz#1435335 is released, we should suggest in our docs the following info message:

~~~
If the hypervisor is booting from SAN, it is recommended to add a drop-in multipath config file for the boot LUN, as showed in the below example. It should help avoid getting the host filesystem read-only, if something going wrong with the boot LUN. 

$ cat /etc/multipath/conf.d/host.conf
multipaths {
    multipath {
        wwid xxxyyy
        no_path_retry queue
    }
}
~~~

Nir, can you ack please?

Comment 2 Nir Soffer 2018-03-19 16:57:09 UTC
This is not a temporary solution until bug 1435335 is resolved, but part of the 
solution for that bug.

Ben, can you confirm that this configuration is enough to enable queuing when
all paths have failed?

Do you recommend additional configuration for this use case?

Comment 3 Ben Marzinski 2018-03-22 20:43:01 UTC
This should work to force queuing on a specific multipath device.

Comment 9 Franta Kust 2019-05-02 11:45:58 UTC
Test sync