"multipathed devices" displayed as if they are seperate devices

[trgill]

When there are multiple paths to the same "multipathed device" - they are displayed as if they are different devices.

I think the "create volume" and "create RAID" windows should use the unique ID of a device to determine if they are the same device. It should only list the device once with an indicator that there are multiple paths to the same device. (provide a list of the paths?)

multipath is very common in enterprise environments.

[stefwalter]

@phatina FYI

[mvollmer]

Yes, I know that there is a thing called multipath, but I don't understand it well enough. I'll catch up.

[mvollmer]

I think the "create volume" and "create RAID" windows should use the unique ID of a device to determine if they are the same device. It should only list the device once with an indicator that there are multiple paths to the same device. (provide a list of the paths?)

What are the /dev/mapper/... entries in the list?

Isn't it so that with multipath, you get a new block device that will 'bond' a number of existing block devices together, and you are then supposed to use that new block device instead of the old ones?

E.g, in your example, we would need to hide all the /dev/sd* entries and somehow figure out that /dev/mapper/ refers to one of the NETAPP drives. Correct?

[trgill]

Yes, the /dev/mapper/... entries are like containers for the underlying paths. In this case there are two paths, but there can be many. When multipath is enabled an application doing IO to the /dev/mapper/xxx device gets fault tolerance and load balancing across the paths.

I think Cockpit has the data to figure out when there are multiple paths. The attached display knows that /dev/sde and /dev/sdc point to the same device.

Could you group the /dev/sd* entries together when they have the same WWN or Serial number? I think that would be better.

Grouping them under the correct /dev/mapper/xxx device would be ideal, but I'm not sure how you'd get that data to make the connection.

[mvollmer]

Grouping them under the correct /dev/mapper/xxx device would be ideal, but I'm not sure how you'd get that data to make the connection.

Let's say we group /dev/sdf and /dev/sdi, and the user selects that entry as a physical volume for a new volume group, how should we create the volume group? Which of the block devices should we pass to vgvreate? Isn't the only proper way to find the right /dev/mapper/ entry and pass that to vgcreate?

In general, I have to admit that I have ignored the possibility of multi path when writing the Cockpit code until now. Storaged/UDisks2 have some understanding of it, but Cockpit will likely show odd behavior with multipath devices. I'll plan to get multipath right soonish, starting within a weeks time or so.

[trgill]

Let's say we group /dev/sdf and /dev/sdi, and the user selects that entry as a physical volume for a new volume group, how should we create the volume group? Which of the block devices should we pass to vgvreate? Isn't the only proper way to find the right /dev/mapper/ entry and pass that to vgcreate?

Could we change "Create Volume/RAID" to group the /dev/sdxx devices together and have some type of indicator that shows they are multiple paths to the same device. But they would not be selectable. The user could select the /dev/mapper/xxx device that is the parent of the underlying paths.

Maybe we could also add a warning to the user that they need to add a filter to the lvm.conf file so that the /dev/sdx devices don't get scanned by the LVM?

We could take a similar approach to the "Drives Panel"?

[trgill]

I think you'll know how to do this better, but something along the lines of this would be good. The serial number/WWN from the /dev/mapper/xxx will match the /dev/sdxx values to group then together.

You are right - we should send all commands down /dev/mapper/xxx.

[mvollmer]

I have some code now in #2596, please check it out.