350-401 Practice Question: Is migrating a physical server running a critical…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  VMFS datastores with multiple extents can cause I/O to span multiple LUNs, increasing latency.

  Why this is correct

  This is correct because a VMFS datastore can be created by concatenating multiple extents, each residing on a different LUN. When a virtual machine's file (VMDK) is stored on such a datastore, I/O operations can be striped or scattered across those physical LUNs. Because separate LUNs often reside on different spindles, RAID groups, or storage tiers, the hypervisor may need to wait for round-trips over multiple paths or controllers, adding per-I/O overhead and increasing latency beyond what a single-extent datastore would incur.

• ✗

  The VMFS datastore does not support files larger than 2 TB.

  Why it's wrong here

  This is incorrect because modern VMFS versions (e.g., VMFS5 and VMFS6) support very large files. The file-size limit for VMFS6 with a 64 KB block size can be up to 62 TB, or even larger depending on the block size and version. While older VMFS versions had lower limits and multi-file extents were historically used to address these constraints, a 2 TB limit is not applicable to current VMFS releases. Therefore, the performance issue is not caused by a 2 TB file-size limitation, but by the datastore's extent configuration.

• ✗

  The virtual disk is configured as thin provisioned, causing write amplification.

  Why it's wrong here

  This is incorrect because thin provisioning affects when and how storage blocks are allocated, but it is not inherently tied to datastore extents. A thin-provisioned virtual disk writes only to allocated blocks on demand; the vSphere storage stack and the underlying array handle that allocation. While thin provisioning can cause write amplification on certain storage (especially flash arrays) due to metadata updates and zeroing on first write, that behavior is a property of the provisioning model, not of spanning multiple LUNs. The question describes a scenario tied to alternating I/O paths across extents, which thin provisioning does not explain.

• ✗

  The virtual disk is configured as thick eager zeroed, causing slow initial writes.

  Why it's wrong here

  This is incorrect because thick eager zeroed disks are pre-zeroed at creation time, so the blocks are already allocated and filled with zeros before the VM runs. During runtime, writes go directly to the blocks without any on-demand allocation or zeroing overhead. The initial deployment or first write to a lazily zeroed disk can be slow, but a thick eager zeroed disk avoids that because initialization happens upfront. Thus, the symptom of increased latency would not be caused by this option; in fact, thick eager zeroed typically provides the best post-creation performance.

Go deeper

Related to this question