[pve-devel] General direct [i]SCSI storage plugin to extend for specific SAN

[Alexandre DERUMIER]

>>Also, it's using NFS for image access and I don't like NFS :) 
>>I wanted to use iSCSI and later move to FC (when we buy adapers and 
>>switches). But volume manipulation code looks cool. 

I have a updated version for proxmox 4.X, but I don't have pushit it to github yet
I think it shouldn't be too difficult to adapt it for iscsi. (take code for volume management from my plugin, and mix with zfs iscsi plugin)



----- Mail original -----
De: "Dmitry Petuhov" <mityapetuhov at gmail.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Lundi 27 Juin 2016 12:02:46
Objet: Re: [pve-devel] General direct [i]SCSI storage plugin to extend for specific SAN

Will it be included in PVE distrib? Installing out-of-tree code to 
servers is little wrong way to go for users... 

Also, it's using NFS for image access and I don't like NFS :) 
I wanted to use iSCSI and later move to FC (when we buy adapers and 
switches). But volume manipulation code looks cool. 

27.06.2016 12:24, Wolfgang Link wrote: 
> Alexandre has written such a plugin for netapp, may be it fits to your 
> needs. 
> 
> 
> https://forum.proxmox.com/threads/proxmox-netapp-storage-plugin.20966/#post-112335 
> 
> On 06/27/2016 11:14 AM, Dmitry Petuhov wrote: 
>> I want to write storage plugin for my Netapp iSCSI SAN. But I'm little 
>> confused what to use as base. 
>> 
>> ISCSIDirectPlugin.pm is first candidate, but currently it looks not very 
>> usable. Am I right understood that the only way to use it is to manually 
>> create LUN on SAN and write its number in VM config via cli? 
>> 
>> ZFSPlugin.pm is more promising candidate, because of its extensibility 
>> via LunCmd/* modules by design. Actually, it could become good general 
>> direct-lun iSCSI plugin, if all ZFS-specific stuff would moved out to 
>> LunCmd/* modules. 
>> 
>> Another consideration is that LunCmd/* plugins can be used by other 
>> transports of nowadays enterprise SANs, like SAS or FC. Their 
>> volume-image-snapshot APIs are often pretty same for different 
>> transports. At same time, actual transport can be masked at PVE side by 
>> multipathd: we could associate SAN-specific image name with its WWN in 
>> LunCmd code and feed qemu with unified devices 
>> /dev/disk/by-id/wwn-0x{$wwn} generated by multipathd. 
>> 
>> Any thoughts? 
>> 
>> _______________________________________________ 
>> pve-devel mailing list 
>> pve-devel at pve.proxmox.com 
>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
>> 
> _______________________________________________ 
> pve-devel mailing list 
> pve-devel at pve.proxmox.com 
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel