Setting Up a Raspberry Pi as an iSCSI Target: Network Block Storage for VMs and Diskless Clients

This site's Raspberry Pi storage content covers Samba and NFS shares, and a more advanced ZFS-backed NAS build for redundancy — all of it file-level storage, where the Pi decides how files are organized and a client just asks for a named file by path. iSCSI is a different layer entirely: it hands a client raw block storage over the network, the same way a locally attached hard drive would present itself, and lets the client's own operating system format and manage it however it wants. That difference matters most the moment you want to boot a diskless client from network storage, back a virtual machine with a dedicated "disk," or give an old laptop a drive without opening its case.

Block Storage vs. File Storage, Concretely

When you mount a Samba share, your computer asks the Pi for files by name and the Pi's filesystem does the actual disk management — you're trusting the Pi's filesystem and its interpretation of permissions, locking, and structure. When you connect to an iSCSI target, your computer sees what looks like a raw, unformatted disk over the network and formats it with its own filesystem of choice (NTFS, ext4, whatever the client needs), completely unaware that the "disk" is actually a file or partition living on a Pi down the hall. This is why iSCSI is the right tool specifically when a client needs to treat the storage as its own disk rather than a shared folder — a Windows machine that wants a dedicated NTFS volume, or a hypervisor that wants a block device to back a VM, rather than a NAS folder everyone's Samba share already handles fine.

What You'll Need

• A Raspberry Pi 4 or 5 with a reasonably fast storage backend — an SD card alone will bottleneck badly under iSCSI's sustained block I/O, so plan on a USB SSD or, ideally, an NVMe-equipped Pi 5 as the actual backing storage.
• A wired Gigabit Ethernet connection — iSCSI over WiFi works technically but the added latency and inconsistency makes it a poor experience for anything beyond casual testing.
• targetcli-fb (the standard Linux LIO iSCSI target management tool) installed on the Pi to configure and serve the target.
• An iSCSI initiator on the client side — built into Windows (iSCSI Initiator in Control Panel), available via open-iscsi on Linux, and natively supported by most hypervisors including Proxmox and ESXi.

Setting Up the Target

Create a backing store first — either a dedicated partition on your attached SSD/NVMe storage, or a large pre-allocated file acting as a virtual disk image, which is the simpler starting point and performs nearly as well on modern storage. Use targetcli-fb to define that backing store as a "fileio" or "block" backstore, then create an iSCSI target (identified by an IQN — iSCSI Qualified Name, a long formatted string that uniquely identifies the target) and attach the backstore to it as a LUN. Configure an access control list (ACL) restricting which client IQNs are allowed to connect — leaving this open to any initiator on your network is the iSCSI equivalent of leaving a drive letter unlocked for anyone to claim, so lock it down to the specific client(s) that should actually see this storage.

Connecting a Client

On a Windows client, the built-in iSCSI Initiator tool discovers the Pi's IP address as a target portal, lists the available targets by IQN, and connects — once connected, the "disk" shows up in Disk Management exactly like a new physical drive, ready to be initialized and formatted. On Linux, open-iscsi's iscsiadm command handles discovery and login from the command line, after which the new block device appears the same way a newly attached USB drive would, ready for a normal mkfs and mount. For a diskless boot setup specifically, the client's network boot firmware (iPXE, or a Pi's own network boot support) points at the iSCSI target as its root device instead of booting from local storage at all — a genuinely different use case from this site's existing Pi network-boot content, which focuses on NFS-rooted diskless Pi fleets rather than iSCSI-backed ones.

Performance Expectations

Pi Model + StorageRealistic ThroughputGood For Pi 4, USB 3.0 SSD, Gigabit Ethernet~80-100 MB/s, network-limitedA single light VM disk, casual diskless client testing Pi 5, NVMe via PCIe adapter, Gigabit EthernetStill ~100-110 MB/s, network-limited despite faster local storageSame ceiling — Gigabit Ethernet is almost always the bottleneck before the Pi's storage is Pi 5, NVMe, 2.5GbE USB adapterMeaningfully higher, closer to the NVMe drive's real ceilingMultiple clients, a real VM workload, anything beyond light single-client use

When This Isn't the Right Tool

If what you actually want is "a folder my devices can read and write files to," iSCSI is the wrong tool and a Samba or NFS share — simpler to set up, easier to recover from a mistake, and natively multi-client-safe — is the right one. iSCSI shines specifically for single-client block access: one VM, one diskless boot target, one Windows machine that wants a dedicated volume. Running the same iSCSI LUN mounted by multiple clients simultaneously without a clustering filesystem designed for that will corrupt data, the same way plugging one hard drive into two computers at once would.

Security Note

iSCSI traffic is unencrypted and largely unauthenticated by default beyond the ACL and optional CHAP username/password layer — treat it strictly as a local-network-only service behind your router, never exposed to the internet, the same caution this site gives every self-hosted service that wasn't built with a public-facing login screen in mind. Enable CHAP authentication at minimum even on a trusted home network, since the ACL alone only checks the client's claimed IQN, which is trivially spoofable by anything already on your network.

For most home shop setups, this is a narrower tool than the NAS and Samba content already on this site — but for the specific case of giving a VM, a diskless client, or a machine that insists on owning its own disk a block device over the network, a spare Pi with decent storage and a wired connection handles it capably, at a fraction of the cost of a dedicated SAN appliance.