A latency-sensitive OLTP VM on AHV is moved from an RF2 container to an EC-X container, and write latency rises. Which storage efficiency placement should an administrator choose to meet the low-latency requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of RF2 like keeping two copies on hand instead of doing math every write; EC-X saves space but adds parity overhead. If your app is latency-sensitive, you want the lower-latency path first. The trap is chasing capacity savings and accidentally moving a hot VM into a rebuild-heavy efficiency tier.
Full Explanation
RF2 stores each block on two nodes using synchronous replication, so a write completes after two local writes without erasure-coding calculations on the primary path. EC-X distributes data and parity across many nodes, improving capacity efficiency but adding encoding, decoding, and rebuild costs that can increase latency for small random I/O. A latency-sensitive workload therefore needs RF2 or a performance-oriented container unless capacity savings are more important than response time. Erasure coding is appropriate for capacity-optimized or less latency-critical data, not as a default for hot VM disks. Compression can reduce capacity but still operates on the data path and does not replace the low-overhead protection model of RF2. Deduplication removes duplicate blocks, which also introduces processing and lookup overhead and is not chosen to minimize latency. Neither compression nor deduplication changes the fact that EC-X parity placement may add write and rebuild overhead compared with two full replicas. Exam caveat: choose the protection and efficiency method from the workload's latency and capacity requirements, not from a global container default. Operational check: review the container's RF or EC-X setting and the VM's storage policy, then compare latency before and after moving the VM to an RF2 container.