[Users] default mutipath.conf config for fedora 18 invalid

[Yeela Kaplan]

Hi Gianluca,
I was wandering if you could help me verify this issue.
Do you still have this fedora 18 setup?
Can you check if it's possible to add an iscsi storage domain with the current vdsm multipath.conf?
And also if we remove getuid_callout from multipath.conf can you add a storage domain then?

Thanks,
Yeela 

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Gianluca Cecchi" <gianluca.cecchi at gmail.com>, "Yeela Kaplan" <ykaplan at redhat.com>
> Cc: "users" <users at ovirt.org>, "Ayal Baron" <abaron at redhat.com>
> Sent: Wednesday, January 16, 2013 9:46:05 AM
> Subject: Re: [Users] default mutipath.conf config for fedora 18 invalid
> 
> On Wed, Jan 16, 2013 at 01:22:38AM +0100, Gianluca Cecchi wrote:
> > Hello,
> > configuring All-In-One on Fedora 18 puts these lines in
> > multipath.conf
> > (at least on ovrt-njghtly for f18 of some days ago)
> > 
> > # RHEV REVISION 0.9
> > ...
> > defaults {
> >     polling_interval        5
> >     getuid_callout          "/lib/udev/scsi_id --whitelisted
> > --device=/dev/%n"
> > ...
> > device {
> >     vendor                  "HITACHI"
> >     product                 "DF.*"
> >     getuid_callout          "/lib/udev/scsi_id --whitelisted
> > --device=/dev/%n"
> > ...
> > 
> > Actually Fedora 18 has device-mapper-multipath 0.49 without
> > getuid_callout;
> > from changelog:
> > 
> > multipath no longer uses the getuid callout.  It now gets the
> >       wwid from the udev database or the environment variables
> > 
> > so the two getuid_callouts lines have to be removed for f18
> > 
> > multipath -l gives
> > 
> > Jan 16 00:30:15 | multipath.conf +5, invalid keyword:
> > getuid_callout
> > Jan 16 00:30:15 | multipath.conf +18, invalid keyword:
> > getuid_callout
> > 
> > I think it has to be considered.
> 
> Hmm, it seems that the title of "Bug 886087 - Rest query add storage
> domain fails on fedora18: missing /sbin/scsi_id" is inaccurate.
> 
> I've marked the bug as an ovirt-3.2 blocker, and nacked the patch
> that
> attempts to fix it http://gerrit.ovirt.org/#/c/10824/
> 
> Dan.
>