You change the Replication Factor (RF) from 3 to 2 on an existing storage container named 'Gold' that currently hosts several running VMs. No data migration is initiated. What is the immediate effect on the existing VM data stored on this container?

Replication factor is a container property, and changing it on a container that already holds data starts a background reconciliation rather than a foreground rewrite. Curator, the AOS MapReduce framework that runs periodic scans, detects extent groups whose replica count no longer matches the container's RF and schedules tasks to fix them. Going from RF3 to RF2, those tasks delete one replica of each extent group, so physical usage drops progressively as the scans complete; going from RF2 to RF3, they create the additional replica on another node or block. New writes follow the new RF as soon as the setting is saved. The VMs keep running and the container stays fully accessible, because RF governs how many copies exist, not whether the container is mounted. Expecting every block to be rewritten at once with heavy I/O misreads the design: Curator throttles background work to protect foreground performance. Expecting capacity to drop instantly is wrong for the same reason, since the extra replicas are removed by background tasks. A container never becomes inaccessible because of an RF change, and VMs do not need to be migrated. Exam caveat: lowering RF also lowers the failures the container can survive, and moving to RF3 requires at least five nodes and a cluster configured for FT2. Operational check: watch Curator activity and the container's usage in Prism, and confirm Data Resiliency status after the scans finish.