1Y0-A25 · Question #107
Which storage type should be used if thin provisioning is required from the XenServer?
The correct answer is A. NFS based. Citrix 1Y0-A25 Exam
Question
Which storage type should be used if thin provisioning is required from the XenServer?
Options
- ANFS based
- BFibre Channel
- CiSCSI software
- DiSCSI hardware
How the community answered
(38 responses)- A84% (32)
- B3% (1)
- C5% (2)
- D8% (3)
Explanation
Citrix 1Y0-A25 Exam
Topics
Community Discussion
10
Wesley A.Nov 16, 2025NFS is the one you want here, and I know because I got this wrong on my first attempt by second-guessing myself toward iSCSI. The correct answer is A, NFS based. XenServer can only do thin provisioning on file-based storage repositories, and NFS is a file-based SR type, which means XenServer controls the actual allocation and can provision VDIs thinner than the stated size. Fibre Channel, iSCSI software, and iSCSI hardware are all block-based SRs, and with block storage the LUN is pre-allocated at the array level, so XenServer has no mechanism to thin provision on top of it. If thin provisioning is a requirement coming from XenServer itself rather than from the storage array firmware, NFS is the only answer in that list that fits.
Nina C.Apr 9, 2026NFS based storage is the right answer here because thin provisioning on XenServer is only supported with NFS, which lets the storage allocate disk space dynamically as virtual disks actually use it rather than reserving the full amount upfront. The block-based options like Fibre Channel and iSCSI, whether software or hardware, do not support thin provisioning from XenServer's perspective because they work with fixed, pre-allocated LUNs.
Thekla S.Nov 8, 2025Thought FC was it, but thin provisioning needs NFS since it virtualizes at the file layer.
Carlos M.Dec 8, 2025NFS supports thin provisioning natively on XenServer, FC and iSCSI do not.
Thekla S.Dec 10, 2025That is broadly right for classic LVM-based SRs, but worth noting that GFS2 SRs introduced thin provisioning support for iSCSI and FC in Citrix Hypervisor 8.1, so the iSCSI limitation is not absolute depending on which SR type you are using.
Giselle K.Nov 30, 2025NFS is the one to reach for here because XenServer handles thin provisioning at the storage layer when you use NFS, meaning the hypervisor itself manages the allocation rather than offloading that control to the array. Quick gut check though, do you remember why hardware iSCSI loses out on this even though the HBA has more horsepower than a software initiator?
Wesley A.Dec 1, 2025Hardware iSCSI hands the I/O path off to the HBA and bypasses Dom0, so XenServer loses the visibility it needs to orchestrate thin provisioning itself, and that control ends up back on the array side where XenServer can not touch it, which is exactly the trap on the exam because raw throughput numbers make the HBA look like the obvious winner.
Ola B.Apr 13, 2026I actually went with C first, software iSCSI, because I had just built a lab where thin provisioning worked fine on that setup and I figured it carried over to XenServer the same way. Then I spun up a quick XenServer test environment and compared storage types side by side, and that is where it clicked for me. NFS is the one that exposes thin provisioning as a native option in XenCenter because the SR is file-based, so XenServer can allocate disk space on demand without needing to carve out a full LUN up front. With Fibre Channel and iSCSI (both hardware and software), you are dealing with block-level storage where the LUN size is fixed at creation on the array side, so thin provisioning has to be handled by the SAN itself if at all, not by XenServer directly.
Ingrid P.Apr 15, 2026The SAN-side vs. hypervisor-side distinction is the key card to make here, and worth a separate note: even when a SAN does thin-provision a LUN, XenServer sees a fixed-size block device and still cannot reclaim freed guest space without VAAI UNMAP support wired up on both ends.
Ingrid P.Apr 2, 2026NFS gives you thin provisioning natively, but do you know why block-based types cannot?