Among multiple virtualization platforms available in the market, Proxmox represents a solid and viable solutions also for the enthusiasts learning, testing and having fun with their homelab deployments. I have been playing with Proxmox VE for quite a while. Past the initial “impact” coming from VMware and how things should work vs. how they actually work, it has been a great learning. Most importantly, Proxmox VE (PVE) overtime shows a tremendous growth, community consensus and adoption, and new features making this platform a sort of swiss knife for server virtualisation and container deployments.
At the time of writing in September 2026, my homelab is still running on Intel NUCs and Synology storage. After wiping clean all the NUC hosts and removing the existing storage volumes, the homelab is now more a testing space for Proxmox, Containers, and local AI models. More on these in separate articles. Also, all the learning and configurations from the previous VMware deployments now live in a different “shape and form” on the PVE nodes. A dedicated article will cover in greater details the networking configurations improving the overall performance along with the best practices.
Proxmox VE allows for different integrations between File and Block storage as well as other interesting and advanced file systems like CephFS and ZFS. In this instance the article covers the steps to add and resize iSCSI storage provided by a Synology SAN. The purpose is to run all the basic steps from the creation of the iSCSI LUNs, iSCSI Targets on the Synology and how to present and integrate these with a Proxmox Datacenter consisting of a 2 nodes cluster. The objective is to share a common storage across 2 PVE nodes. High Availability on Proxmox Cluster is outside the scope of this article and it will be covered separately at a later stage. The rest of the article goes as the following:
- Create a Synology Storage Volume
- Create an iSCSI LUN on Synology
- Create a iSCSI Target on Synology
- Adding Proxmox iSCSI Initiators
- Setting Synology iSCSI Target LUN permissions
- Adding iSCSI Targets to Proxmox Nodes
- Resize the iSCSI Target size for Proxmox Nodes
Create a Synology Storage Volume
The first step is to provide a Volume from the space in the Storage Pool from the Synology NAS. In this example the model used is a DS916+ with an up to date DSM release. The steps are pretty much similar if not the same with other Synology models. It goes without saying, same principles are applicable to other vendors as these are basic operations when providing iSCSI LUNs to be consumed from hosts. In this example the Storage Pool aggregates about 2.8 TiB of which 565 GiB have been already allocated leaving 2.3 TiB available for other Volumes to be created. In this instance the Volume that will be created will use intentionally 931 GiB (about 1 TB) and only half will be initially used for the iSCSI LUN to present to the PVE nodes. This allows for the next steps demonstration on increasing the size from half terabyte to full 1 TB available to the same PVE hosts.
A wizard is starting allowing to choose and review the basic details. Although the available capacity in the Storage Pool is roughly 2.3 TiB, just 931 GiB will be used. It is worth noting the allocated size can be increased at any time. Assuming the Storage Pool is expanded with additional physical disks (same or bigger size) and depending on RAID type, this allows for further increase to the allocated size. The Volume capacity in the Storage Pool is not strictly related to the size of the iSCSI LUNs created later. The Storage Pool is the underlying hardware layer presented to the hardware controller which is configured to present the LUNs.
In the next step, the file system choice between Btrfs and ext4. The former is the defacto standard for advanced features including snapshots, replication and in general data protection tasks. Ext4 remains a stable choice for older hardware due to its longevity. Btrfs remains a strong option.
In the final screen, the option to review main settings and go back to amend changes. It is worth noting the current size for storage is measured in GiB / TiB vs. GB / TB.
At this point the Synology Storage Manager Dashboard is populated with the newly created Volume in the Storage Pool. A quick hover with the mouse reveals the Used, Free, Total space. These are net of the storage space used by RAID and Synology software to manage the striping and the physical blocks underneath.
Create an iSCSI Target on Synology
Now that the Synology Volume is available from the Storage Pool, next step is to create the iSCSI Target, LUN and the basic settings and permissions for the PVE hosts allowed to connect using their iSCSI initiators. The SAN Manager Dashboard is a quick way to review the allocated resources.
Creating a new iSCSI Target brings the wizard. Name could be anything, “Target-LVM” in this case. Ideally something more meaningful and consistent naming convention is always a better idea. Very important is also the IQN number which uniquely identifies this resource and it’s helpful for discovery, logging, configuration and troubleshooting scenarios. It is also possible to enable the CHAP (Challenge Handshake Authentication Protocol) which allows to protect iSCSI storage connections by identifying the identities of both the client initiator (PVE host in this case) and the storage device (Synology DS916 in this case). CHAP can be set as uni-directional or bi-directional where authentication happens both ways. CHAP eliminates the risk of unintended clients to initiate connections with existing storage targets.
In the next step the option to map an iSCSI LUN with the ability to choose an existing one, create a new one or even revisit this process later as indicated by the selected option.
A final screen to review the main settings and go back in case of changes. Done to complete the wizard.
At this point the SAN Manager Dashboard shows the iSCSI Target ready to be used.
Create an iSCSI LUN on Synology
From the SAN Manager Dashboard, next step is to create an iSCSI LUN to associate or map to the iSCSI Target previously created.A new wizard will guide through the main settings. Name can be anything, same as per Description field. The Location is important and in this case the newly created Volume in the Storage Pool is selected. When it comes down to the Total capacity, it will be reflected to the storage space that will be visible to the client initiators on the PVE hosts. Although a full 893 GiB could be used, about half will be used to help demonstrate the next bit in case more space is needed. The typical example would be VM storage running out of space. When the Storage Pool can accommodate more “physical” space, it is possible to increase the size of the Volume followed by the Total capacity for the LUN. While these changes are immediate on the storage size, the initiator clients might need to rescan or logoff from the current iSCSI session to reflect the current changes. Older hosts might need to manually force the rescan of the disk block to see changes. It is shown later in this article. Finally the Space allocation can be either Thick or Thin Provisioning. The latter allows for more flexibility including the ability (where supported) to run Space reclamation. For example Thin provisioned disks for VMs shrinking their size and allow the storage controller to reclaim the “unwanted” space again.
The following screen shows the creation of a new iSCSI Target or the option to choose the one previously created. Naming convention is key and especially when dealing with multiple resources and accessing them over long periods.
At this point it is possible to assign the access permissions from the initiator clients on the PVE hosts to the iSCSI Target. Since no host has been specified yet, the Allow all is the only viable option. These mappings can be adjusted at a later time when needed.
And a final screen to review main settings and going back in case of changes.
Adding iSCSI Initiators
Now that the iSCSI Target and LUN have been created next step is to create a policy which allows specific Hosts (PVE nodes in this case) to connect to the defined Target. As per usual from the main SAN Manager Dashboard > Host to start the wizard.
The Name field can reflect the current hostname of the node or a sample one. Same goes for the Description field. From the Operating System field the selection is Linux as Proxmox VE is based on Debian distibution. Next step is about looking for the unique identifier from the PVE nodes.
The quickest way to find the IQN ID from the initiator clients is to look at the content of initiatorname.iscsi file. A simple cat /etc/iscsi/initiatorname.iscsi will reveal the full IQN number. This can be done either connecting from the Node Shell within the Proxmox GUI or connecting via SSH to the pertinent PVE host like screenshot below.
At this point it is possible to copy to IQN number in the wizard. In this case the IQN has been added manually.
Next is about the Permissions for the PVE node. A full Read / Write is required to create and run Proxmox VMs and / or containers.
A final screen to review and change setting where needed.
At this point the Host section shows the first PVE node successfully added to the configuration.
By repeating the same steps for all the other PVE nodes, these will appear in the Host view.
Synology iSCSI Target LUN permissions
Now that all the desired PVE Hosts have been added as iSCSI client initiators next step is to review the general settings for the available Target. In particular in the advanced section the “Allow multiple sessions from one or more iSCSI initiators” should be selected in particular when operating with multiple clients concurrently as the case for this configuration.Another important setting is the size of the max sed and receive segment in bytes which measure the size of the transmitted packets and payloads parameters over the TCP connection. 262144 bytes or 256KB represents the standard size. It is worth checking the default parameters configured for the iscsiadm service or similar to avoid fragmentation. The iscsiadm shipping with PVE nodes come with these parameters by default.
Another important steps in the Network Binding section is to make sure the intended network interface is selected for the iSCSI traffic. Even better when this is isolated in VLAN. More on these settings and best practices will be covered in a dedicated article.
Adding iSCSI Target to Proxmox Nodes
Now that the configuration side on the Synology is completed, next is to create prepare the PVE nodes as client initiators. This particular example shows the steps from a Proxmox datacenter. The process is very similar when adding single PVE hosts. From Datacenter view > Storage > Add > iSCSI will start the wizard to import the iSCSI connection before adding the iSCSI storage Target.
In the wizard, the ID can be anything, the Portal needs to be either the DNS name or the IP Address of the iSCSI Target Portal. In this case the IP or DNS of the Synology. As soon as the details are entered, the wizard will automatically show all the available Targets to choose from. Should the Target list lag or fail to load that is an indication of an issue with the network and / or name resolution. Since this Target will be used by multiple PVE hosts, the Nodes filed can be left blank, All nodes can use and no restrictions on specific nodes. To make this configuration active the Enable option needs to be checked. Use LUNs direclty needs to be unchecked as the LUNs will be managed via LVM or LVM-Thin.
Another important check before proceeding is to make sure there are less hops as possible between the nodes and the target storage like it is shown in the screenshot. A simple way to determine this is to run a traceroute command from the PVE Shell which shows a single hop or better a direct connection from the PVE nodes and the target storage. The more hops, more chances of performance degradation and bottlenecks to troubleshoot.
Now everything is ready to import the iSCSI connection to create a LVM configuration to access the iSCSI storage Target. From Datacenter view > Storage > Add > LVM a new wizard is presenting the basic options.
ID can be anything. Base Storage is the available connection created earlier. It automatically populates the Base volume. In this case is Channel 00 ID 0 LUN 1. Best practise is to have 1 LUN per Volume. The Volume Group can be anything and can be reused later when adding more LUNs / Volumes from the same Portal. As per the Content, this can be used for VM Disk Images and Proxmox LXC Containers. All the nodes in the Datacenter are allowed with no restrictions. This LVM storage needs be Enabled in order to be visible to the PVE hosts. Since multiple nodes will be accessing same LUN the Shared checkbox is enabled. Wipe Removed Volumes should be used with caution avoiding to remove VM disks that should be available to other nodes accessing same LVM storage. The Advanced option will be covered in a separate article. Click Add once ready.
Now to test the new LVM storage on top of iSCSI connection is working, could simply start a new wizard to create a new VM and in Disk section the storage will now show the iSCSI storage just provided.
Simply visiting the Summary page for the iSCSI storage it show the allocated LVM disk and the available space.
Increase the iSCSI Target size for Proxmox Nodes
What if the current iSCSI storage is running out of space for the VMs or maybe a VM is outgrowing and more space is needed? This is where the following steps come handy to check the current state of play and see the possible options. First of all by logging into any of the PVE hosts connected with the iSCSI storage a simple “lsblk” or “lsblk -S” will return the available block storage. The screenshot below shows /dev/sdb/ with roughly 465 GB and definitely the one provided by the Synology.
As a confirmation, on the Synology SAN Manager the LUN section shows the same information. What if the iSCSI LUN storage needs to be extended?
At this point in order to increase the size of the existing LUN, with the LUN selected and then Edit, it will show the LUN settings. In the Properties section it shows the Total capacity set to 465 GiB.
From the Synology Storage Pool, the Volume 3 it was set to 931 GiB. This is also shown in the Location field where the space left to grow the LUN is about 893 GiB. In real life other the Storage Pool is physically expanded by replacing the HDD/SSD with bigger ones or a new Volume is created in the same or new Storage Pool pending the available physical space.
By hitting on Save, now the LUN shows a Total capacity of 893 GiB.
Running the “lsblk” command on the PVE Host it now shows the newly expanded size for the sdb block storage.
While the physical size has increased the new disk geometry has not been acquired by the kernel. This is simply shown by running a “vgscan” to list all the Volume Groups and vgdisplay vg-ds916 (in this example) to list the properties where the VG size is still showing the previous value for the disk geometry at rougly 465 GiB
Issuing the “pveresize -v /dev/sdb/” in this example it shows a verbose output of the dry run when trying to extend the storage to the new size. It shows no errors (1 physical volume(s) resized or updated / 0 physical volume(s) not resized). By issuing the same command as “pvresize /dev/sdb” in this example, will now resize and update the metadata information about the new disk geometry.
This can be confirmed by issuing a vgdisplay command and check the new VG size now showing the expected 893 GiB.
It is now time to check the Summary page for the “Vol-LVM” already reflecting the newly updated size close to 1 TB from the initial 500 GB.
Separate articles will focus on performance, available features, configurations and best practices when using iSCSI vs. File storage.
Add Comment