Sorry for the wrong formatting, below again with the correct quoting. Hi Felix, Sorry for the late reply. I missed the mail.
> Before we start implementing we'd like to know if there are any related > ongoing/past developments and if such changes fit the project. > > These are changes we plan to contribute: > > 1. Improvements to the GUI: > a) Better Disk Image names, when configuring a VM with iSCSI > (Multipath) Storage: > Currently, Disk Images have Names such as "CH 00 ID 0 LUN > 0", which are hard to correlate to Disks on the iSCSI System. Instead, > additional Information such as WWID should be visible. That sounds like a good idea! So far I'm not aware of anyone working on that. It might be useful as well to show which multipath they are a part of. > > b) Addition of Multipath path healthiness to the GUI (as can be > seen with multipath -ll) That's probably going to be difficult. We don't show the multipath devices anywhere separately. But for this we would probably need an overview over all configured multipath devices. This could be something for when we make multipath configurable via our tooling and GUI. > > 2. Changes to iSCSI Configuration: > a) Addition of optional CHAP Authentication > b) Configuration of multiple Discovery Portals for iSCSI > storage’s, in case iSCSI systems do not announce all Portals I'm currently working on a storage mapping series [0]. In there we could probably add support for CHAP authentication as well, once we have it in the current plugin for the simple case. So feel free to work on CHAP authentication for now. There will be lots of changes coming to the ISCSIPlugin though. Regarding multiple discovery portals, we don't currently support separate discovery portals. The portal that is configured as part of the storage, is one we expect to be reachable all the time, as otherwise the storage will not be shown as `active`. But adding discovery portals to the storage mapping series does make sense. I'll see if I can add it to the v2 of the series. I'm not sure it makes sense to add discovery portals to the current plugin. I'd rather prefer using the mapping way instead. > > 3. Resize/Re-scan & other Life-cycle features The issue with those is, that it always depends on the SAN if it works by default or not. > > a) Addition of a refresh button or something similar to fetch > LUN Information again > That should already be done by default on every pvestatd update loop > iteration, no? > > b) Online resize of LUNs (visible on Hypervisor as well as in > VM); Either automatically or with a manual refresh button Having a button to run `rescan-scsi-bus.sh -s` or whichever command is required, could make sense. Since we don't install sg3-utils by default, that button would have to be optionally enabled when it is available. Or maybe we could start depending on it in the future. > > c) deletion and cleanup of unused LUNs A colleague tested this previously, and it's not easily doable. AFAIK you would have to manually remove the SCSI devices via /sys/devices/.../remove? Or are you aware of a simple way to remove LUNs? > > 4. LVM Support for Multipath Devices > a) Creation of LVM-PVs on Multipath Devices using the GUI/CLI It uses the multipath devices if those are available. Even if you only create the multipath after the LVM. But maybe the selection list could be extended with the wwid and multipath device? That way you would see if any multipath device is configured. > > We'd appreciate feedback if any/all of these changes or of interest and > if we can move forward with implementing them. > > Regards, > > Felix Drießler > [0] https://lore.proxmox.com/pve-devel/[email protected]/T/#t _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
