1Y1-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 1Y1-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
(18 responses)- A83% (15)
- B6% (1)
- C11% (2)
Explanation
Citrix 1Y1-A25 Exam
Topics
Community Discussion
11NFS is the answer here. With NFS-based storage, XenServer handles thin provisioning at the VHD layer, so virtual disks only consume space as data is actually written rather than pre-allocating the full disk size up front. Fibre Channel and iSCSI (both hardware and software initiator) present block-level LUNs to XenServer, and at that layer the SR either uses fixed allocation or depends on array-side thin provisioning that XenServer itself does not control. If the exam is asking specifically about thin provisioning coming from XenServer rather than from the storage array, NFS is the only option where that capability lives in the hypervisor stack.
I honestly went with C first because iSCSI software felt more "flexible" to me, but then I remembered that thin provisioning on XenServer depends on file-based storage where the hypervisor controls allocation, and NFS fits that since it lets XenServer manage the blocks itself rather than the SAN doing it. NFS is the one that gives you thin provisioning from the XenServer side, so A is the answer.
NFS is right, though "thin provisioning from XenServer" really means from Storage Manager, not FC or iSCSI HBA.
Right on the SM layer, but worth flagging for exam purposes that array-side thin provisioning on FC or iSCSI targets is still a real concept, so blueprints may test whether you can separate host-side Storage Manager behavior from array-side provisioning decisions made at the target.
Thin provisioning is the one that trips people up here because iSCSI sounds so enterprise-grade that it feels like it should do everything, and that instinct will cost you points. The reason NFS wins is that XenServer stores virtual disk images on NFS as VHD files, and VHD files can grow on demand rather than reserving the full declared size upfront, which is exactly what thin provisioning means. Block-level storage types like Fibre Channel and both flavors of iSCSI go through LVM in XenServer, and LVM allocates the full logical volume at creation time, so you get thick provisioning whether you want it or not. The answer is A, and once you tie the underlying mechanism (file-based versus block-based) to the behavior, you will not mix these up again.
Good breakdown, and worth flagging for the exam that EXT local SRs qualify for thin provisioning alongside NFS because both store VHDs on a filesystem, so the clean dividing line to memorize is file-based SR versus LVM-based SR, not NFS versus everything else.
I went with iSCSI software first because software-based just feels more flexible and manageable than a dedicated NFS share, but then I remembered that XenServer thin provisioning works at the file level, meaning it needs a storage type that hands it actual files to grow on demand, and NFS is exactly that, a file system you mount over the network where your VHDs can start small and expand as data gets written, while iSCSI and Fibre Channel hand you a raw block device that XenServer has to carve up all at once like buying the whole loaf when you only needed one slice.
NFS all day, baby! Thin provisioning lives on NFS because XenServer delegates space management to the file system.
Right idea, but picture the VHD file as a balloon that only inflates as data fills it, so the thin provisioning credit really belongs to the sparse VHD format riding on top of NFS, with NFS just being the landlord willing to hold that deflated balloon until it grows.
NFS is the one storage type here that lets XenServer allocate disk space dynamically rather than reserving the full amount upfront, which is the whole point of thin provisioning, and that distinction alone eliminates the three block-level options. Here is my clarifying question for the group: can you explain WHY block-level storage types like Fibre Channel and iSCSI force thick provisioning in XenServer, and what architectural difference in their storage repositories locks them into that behavior?
NFS hands the thick-vs-thin decision to the file system, so XenServer just writes a sparse file and the datastore does the accounting, while FC and iSCSI hand you raw block extents that the SR has to carve and reserve up front because there is no underlying file system layer to defer that allocation.