This is in response to the request for developers to work on Ceph on Windows. My background is in Windows development so I’m going to jump into this conversation. I’m curious about the results of the Ceph on Windows survey. Specifically, this question arises: For those who want to use Windows, what role do they see Windows playing in their Ceph deployments? Here are the possibilities as I see them: - Native Windows implementation of core Ceph components - Run the Ceph server components as Linux VMs in Windows HyperV - Windows client using NVMe-OF initiator for locally attached disks and/or HyperV virtual disks for local VMs connecting to Ceph’s NVMe-OF target. - Native Ceph client on Windows serving up block devices as a locally attached disk and/or HyperV virtual disks for local VMs - Something else? Let’s take these one at a time starting from the top: - I don’t think anyone is seriously proposing the porting of Ceph to native Windows executables as the effort involved is significant for very little benefit. Correct? - The “running Ceph components inside of HyperV” is already fully supported from the Windows HyperV standpoint. These VMs can deliver decent performance relative to running on bare metal by leveraging existing Direct Device Attachment feature for direct access to storage devices. There is nothing the Ceph team needs to do here to make this work. - Accessing Ceph through the NVMe-OF/TCP protocol. For Microsoft in-box solutions this is limited to Windows Server 2025 and later. There is a solution from StarWind that addresses this for earlier releases of Windows (though I have no idea if that product has the quality required). - For the native Ceph client (at https://github.com/ceph/wnbd), it seems like this code may work for some customers that don’t want to use NVMe-OF but this code is not currently maintained since the last update was three years ago. Is there another repo that implements the Windows client that is up to date? - And lastly, is there some other role the respondents see for Windows that I haven’t included? It seems to me that unless there are shortcomings in either the Windows NVMe-OF initiator or the Ceph NVMe-OF target that the best way to support Windows clients is via NVMe-OF. What are the shortcomings that lead you toward putting effort into the native Ceph client for Windows? Here is a bit about myself for those who want to know about my background. I worked as a developer on storage technologies for Microsoft from 1990 until I retired in September 2025. Here's a quick list of some of the things that I worked on for Microsoft that may be relevant to Ceph: - SMB Server (as lead) - LDAP client - WebDAV client - VHD mount and boot - NTFS file system (designed much of the tiered storage and thinly provisioned architecture) - REFS file system (as lead) - DFS - Storage Spaces - Azure fabric controller - Azure XStore storage client - Azure UltraDisk client (as lead) - Azure Boost host driver and firmware My goal is to help organizations with data sovereignty and scalable on-premise storage solutions. I'm interested in helping the Ceph team and I know quite a bit about Windows storage. I'm looking forward to continuing the talk about what the Ceph team needs help with. Thanks for the conversation. -Andy Herron andy.herron@proton.me