On 21 Jul 2017, at 15:12, Yaniv Kaul 
<yk...@redhat.com<mailto:yk...@redhat.com>> wrote:

On Wed, Jul 19, 2017 at 9:13 PM, Vinícius Ferrão 
<fer...@if.ufrj.br<mailto:fer...@if.ufrj.br>> wrote:

I’ve skipped this message entirely yesterday. So this is per design? Because 
the best practices of iSCSI MPIO, as far as I know, recommends two completely 
separate paths. If this can’t be achieved with oVirt what’s the point of 
running MPIO?

With regular storage it is quite easy to achieve using 'iSCSI bonding'.
I think the Dell storage is a bit different and requires some more 
investigation - or experience with it.

Yaniv, thank you for answering this. I’m really hoping that a solution would be 

Actually I’m not running anything from DELL. My storage system is FreeNAS which 
is pretty standard and, as far as I know, iSCSI practices dictates segregate 
networks for proper working.

All other major virtualization products supports iSCSI this way: vSphere, 
XenServer and Hyper-V. So I was really surprised that oVirt (and even RHV, I 
requested a trial yesterday) does not implement ISCSI with the well know best 

There’s a picture of the architecture that I take from Google when searching 
for ”mpio best practives”: 

Ans as you can see it’s segregated networks on a machine reaching the same 

In my case, my datacenter has five Hypervisor Machines, with two NICs dedicated 
for iSCSI. Both NICs connect to different converged ethernet switches and the 
iStorage is connected the same way.

So it really does not make sense that a the first NIC can reach the second NIC 
target. In a case of a switch failure the cluster will go down anyway, so 
what’s the point of running MPIO? Right?

Thanks once again,

May we ask for a bug fix or a feature redesign on this?

MPIO is part of my datacenter, and it was originally build for running 
XenServer, but I’m considering the move to oVirt. MPIO isn’t working right and 
this can be a great no-go for me...

I’m willing to wait and hold my DC project if this can be fixed.

Any answer from the redhat folks?


> On 18 Jul 2017, at 11:09, Uwe Laverenz 
> <u...@laverenz.de<mailto:u...@laverenz.de>> wrote:
> Hi,
> Am 17.07.2017 um 14:11 schrieb Devin Acosta:
>> I am still troubleshooting the issue, I haven’t found any resolution to my 
>> issue at this point yet. I need to figure out by this Friday otherwise I 
>> need to look at Xen or another solution. iSCSI and oVIRT seems problematic.
> The configuration of iSCSI-Multipathing via OVirt didn't work for me either. 
> IIRC the underlying problem in my case was that I use totally isolated 
> networks for each path.
> Workaround: to make round robin work you have to enable it by editing 
> "/etc/multipath.conf". Just add the 3 lines for the round robin setting (see 
> comment in the file) and additionally add the "# VDSM PRIVATE" comment to 
> keep vdsmd from overwriting your settings.
> My multipath.conf:
>> defaults {
>>    polling_interval            5
>>    no_path_retry               fail
>>    user_friendly_names         no
>>    flush_on_last_del           yes
>>    fast_io_fail_tmo            5
>>    dev_loss_tmo                30
>>    max_fds                     4096
>>    # 3 lines added manually for multipathing:
>>    path_selector               "round-robin 0"
>>    path_grouping_policy        multibus
>>    failback                    immediate
>> }
>> # Remove devices entries when overrides section is available.
>> devices {
>>    device {
>>        # These settings overrides built-in devices settings. It does not 
>> apply
>>        # to devices without built-in settings (these use the settings in the
>>        # "defaults" section), or to devices defined in the "devices" section.
>>        # Note: This is not available yet on Fedora 21. For more info see
>>        # https://bugzilla.redhat.com/1253799
>>        all_devs                yes
>>        no_path_retry           fail
>>    }
>> }
> To enable the settings:
>  systemctl restart multipathd
> See if it works:
>  multipath -ll
> HTH,
> Uwe
> _______________________________________________
> Users mailing list
> Users@ovirt.org<mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users

Users mailing list

Users mailing list

Reply via email to