[Users] default mutipath.conf config for fedora 18 invalid
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. Gianluca
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.
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@redhat.com> To: "Gianluca Cecchi" <gianluca.cecchi@gmail.com>, "Yeela Kaplan" <ykaplan@redhat.com> Cc: "users" <users@ovirt.org>, "Ayal Baron" <abaron@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.
On Wed, Jan 23, 2013 at 2:34 PM, wrote:
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
I can confirm that the environment is still present. It is the same as at this other thread: http://lists.ovirt.org/pipermail/users/2013-January/011593.html I confirm that after - removing getuid_callout entry - blacklisting devices that was part of clustered volumes (pre-existing CentOS 6.3 + KVM nodes I'm migrating to oVirt) I was able to successfully create FCP storage domain (see myself follow up of thread above) To add iSCSI domain I need to have another host, correct? As I can't mix FCP and iSCSI domain types for the same host/cluster.... Gianluca
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Yeela Kaplan" <ykaplan@redhat.com> Cc: "users" <users@ovirt.org>, "Ayal Baron" <abaron@redhat.com>, "Dan Kenigsberg" <danken@redhat.com> Sent: Wednesday, January 23, 2013 4:05:34 PM Subject: Re: [Users] default mutipath.conf config for fedora 18 invalid
On Wed, Jan 23, 2013 at 2:34 PM, wrote:
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
I can confirm that the environment is still present. It is the same as at this other thread: http://lists.ovirt.org/pipermail/users/2013-January/011593.html
I confirm that after - removing getuid_callout entry - blacklisting devices that was part of clustered volumes (pre-existing CentOS 6.3 + KVM nodes I'm migrating to oVirt)
I was able to successfully create FCP storage domain (see myself follow up of thread above)
Thanks
To add iSCSI domain I need to have another host, correct? As I can't mix FCP and iSCSI domain types for the same host/cluster....
Yes, you need a different DC and host for iSCSI SDs.
Gianluca
On Wed, Jan 23, 2013 at 4:41 PM, Yeela Kaplan wrote:
Yes, you need a different DC and host for iSCSI SDs.
Possibly I can test tomorrow adding another host that should go into the same DC but I can temporarily put it in another newly created iSCSI DC for testing. What is the workflow when I have a host in a DC and then I want to put it into another one, in general and when the two DCs have configured different SD types?
----- Original Message -----
On Wed, Jan 23, 2013 at 4:41 PM, Yeela Kaplan wrote:
Yes, you need a different DC and host for iSCSI SDs.
Possibly I can test tomorrow adding another host that should go into the same DC but I can temporarily put it in another newly created iSCSI DC for testing. What is the workflow when I have a host in a DC and then I want to put it into another one, in general and when the two DCs have configured different SD types?
As long as the host has visibility to the target storage domains, all you need to do is put the host in maintenance and then edit it and change the cluster/dc it belongs to.
Hi, I've tested the new patch on fedora 18 vdsm host (created iscsi storage domain, attached, activated) and it works well. Even though multipath.conf no longer uses getuid_callout to recognize the device's wwid, it still knows how to deal with the attribute's existence in the conf file when running multipath command (only output is to stdout which we don't use anyway, stderr empty and rc=0). The relevant patch is: http://gerrit.ovirt.org/#/c/10824/ Yeela ----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> Cc: "users" <users@ovirt.org>, "Dan Kenigsberg" <danken@redhat.com>, "Yeela Kaplan" <ykaplan@redhat.com> Sent: Wednesday, January 23, 2013 7:51:28 PM Subject: Re: [Users] default mutipath.conf config for fedora 18 invalid
----- Original Message -----
On Wed, Jan 23, 2013 at 4:41 PM, Yeela Kaplan wrote:
Yes, you need a different DC and host for iSCSI SDs.
Possibly I can test tomorrow adding another host that should go into the same DC but I can temporarily put it in another newly created iSCSI DC for testing. What is the workflow when I have a host in a DC and then I want to put it into another one, in general and when the two DCs have configured different SD types?
As long as the host has visibility to the target storage domains, all you need to do is put the host in maintenance and then edit it and change the cluster/dc it belongs to.
On Thu, Jan 24, 2013 at 10:44:48AM -0500, Yeela Kaplan wrote:
Hi, I've tested the new patch on fedora 18 vdsm host (created iscsi storage domain, attached, activated) and it works well. Even though multipath.conf no longer uses getuid_callout to recognize the device's wwid, it still knows how to deal with the attribute's existence in the conf file when running multipath command (only output is to stdout which we don't use anyway, stderr empty and rc=0). The relevant patch is: http://gerrit.ovirt.org/#/c/10824/
Given your verification, and the fact that this patch is a step forward, I've taken it into vdsm master and acked it for ovirt-3.2. I trust Ben Marzinski to shout at us loudly if keeping the outdated verb is terribly wrong. I'd expect to see a future patch, adding getuid_callout only for multipath versions that actually need it.
On Fri, Jan 25, 2013 at 10:53:51PM +0200, Dan Kenigsberg wrote:
On Thu, Jan 24, 2013 at 10:44:48AM -0500, Yeela Kaplan wrote:
Hi, I've tested the new patch on fedora 18 vdsm host (created iscsi storage domain, attached, activated) and it works well. Even though multipath.conf no longer uses getuid_callout to recognize the device's wwid, it still knows how to deal with the attribute's existence in the conf file when running multipath command (only output is to stdout which we don't use anyway, stderr empty and rc=0). The relevant patch is: http://gerrit.ovirt.org/#/c/10824/
Given your verification, and the fact that this patch is a step forward, I've taken it into vdsm master and acked it for ovirt-3.2. I trust Ben Marzinski to shout at us loudly if keeping the outdated verb is terribly wrong.
There's no harm at all in using invalid keywords in multipath.conf. It just prints a warning message.
I'd expect to see a future patch, adding getuid_callout only for multipath versions that actually need it.
participants (5)
-
Ayal Baron -
Benjamin Marzinski -
Dan Kenigsberg -
Gianluca Cecchi -
Yeela Kaplan