Adding Datacore-recommended udev rules and multipath rules for XAPI/sm

[ylebris]

This commit integrates Datacore-recommended udev rules and multipath rules for XAPI.

Key changes:

• Implemented udev rules to adjust time for DataCore volumes.
• Implemented multipath rules for DataCore volumes.
• Ensured compliance with existing XAPI storage management (SM) conventions.
• Verified functionality through test scenarios to avoid regression with non-DataCore configurations.

Motivation:
These changes aim to improve performance and reliability for deployments using DataCore arrays, adhering to vendor-recommended best practices while maintaining compatibility with the broader XAPI ecosystem.

Testing:

• Manually verified udev rules on test systems with DataCore arrays.
• Confirmed compatibility with non-DataCore environments.
• Ran unit tests for related storage subsystems.

This change is backward-compatible, introduces no breaking changes and only affect DataCore arrays.

[MarkSymsCtx]

We are actually in the process of deprecating the multipath.conf in this repository, it's no longer being used as responsibility for managing this file has reverted to the owning package, that being device-mapper-multipath.

[ylebris]

We are actually in the process of deprecating the multipath.conf in this repository, it's no longer being used as responsibility for managing this file has reverted to the owning package, that being device-mapper-multipath.

Very clear.

In that case, I will let you close this PR.

[ydirson]

We are actually in the process of deprecating the multipath.conf in this repository, it's no longer being used as responsibility for managing this file has reverted to the owning package, that being device-mapper-multipath.

So what would be the channel now for sending such contributions?

[olivierlambert]

Same question. I think it's at least very useful to be able to contribute on this kind of configuration right on Github.

[ylebris]

For your information, I spend a lot of time with manufacturers to obtain this type of information.
I know that you do the same.

I can get vendor validation here.

You want to separate the elements, fine: give the instructions and the elements. But to do it properly.

[MarkSymsCtx]

Abd that place is here - https://github.com/opensvc/multipath-tools

[olivierlambert]

I'm not sure to get it, you are pointing to the upstream Multipath project, right? We are talking about the multipath config file used by both downstreams of "XAPI Project" in here: XenServer and XCP-ng. I don't see there the file that will be used in there in that upstream repo, can you point me to it?

[MarkSymsCtx]

Precisely, vendor recommended multipath configuration should be sent to the upstream maintainers of multipath and from there it can be consumed into distributions either by updating the build of multipath or backporting the relevant commits. The storage manager has no business thinking it can take ownership of the multipath configuration of the system and for XenServer 9 onwards it no longer does.

[MarkSymsCtx]

And udev updates should go to - https://github.com/systemd/systemd/tree/main/rules.d really

[ylebris]

You know very well that our configurations are specific to hypervisors.

Why?

[olivierlambert]

I understand very well your point but still, such a big change should be done in cooperation and pointing directly where to do the upstream changes (you haven't answer yet which file precisely will replace the multipath.conf in the upstream repo). This is how open source works, in cooperation 🙂

You cannot take unilateral decision and not giving some context or any clue on the new way to do it after (without having us to ask multiple times), otherwise it could be seen as voluntary obstruction.