12.1 Volume Groups, vDisk Placement, and Live vDisk Migration
Key Takeaways
- A volume group is a collection of virtual disks presented over iSCSI, used for shared-disk clusters, bare-metal servers, and VMs that need storage independent of their own configuration.
- Volume groups can be directly attached to a guest VM without an in-guest iSCSI initiator, or exposed over the network to external initiators controlled by an access list.
- Changing vDisk placement means migrating a virtual disk from one storage container to another so it inherits that container policies for replication factor and data efficiency.
- Live vDisk migration across storage containers moves a disk while the VM keeps running, so a policy change no longer requires downtime.
- The three storage types Objective 2.3 asks you to identify are the storage pool, the storage container, and the volume group.
12.1 Volume Groups, vDisk Placement, and Live vDisk Migration
Two knowledge statements land here. Objective 2.1 asks you to "configure storage for VMs" and to "change vDisk placement." Objective 2.3 asks you to "identify the different storage types." Both go beyond the storage-pool-and-container hierarchy covered in section 4.1.
The Storage Types You Must Distinguish
| Type | What it is | Consumed as |
|---|---|---|
| Storage pool | The aggregate of physical drives across the cluster | Not consumed directly; it is the capacity substrate |
| Storage container | A logical, policy-bearing subdivision of the pool | Presented to hosts as a datastore; holds vDisks |
| Volume group | A set of vDisks presented over iSCSI | Attached to VMs or to external initiators as block devices |
The distinction that matters: a normal VM disk lives in a storage container and is attached through the hypervisor. A volume group presents block storage over iSCSI, which is what lets consumers outside the normal VM disk model use Nutanix storage.
Volume Groups
A volume group is a container for one or more virtual disks, presented as an iSCSI target. It is the administrative unit of Nutanix Volumes (section 9.3).
Two ways to attach a volume group
Direct attachment to a VM. Prism can attach a volume group straight to a guest VM. The guest sees additional disks and needs no in-guest iSCSI initiator configuration — the platform handles the connection. This is the simpler path and the one used when a single VM needs storage that should exist independently of the VM's own configuration.
External initiators over the network. The volume group is exposed as an iSCSI target on the network, and consumers connect using their own iSCSI initiator identified by its IQN (iSCSI Qualified Name). An access list on the volume group controls which initiators are permitted to attach. This is how bare-metal physical servers and clustered applications consume Nutanix storage.
When to use a volume group instead of a normal VM disk
- Shared-disk clustering. Windows Server Failover Clustering, Oracle RAC, and similar designs require several nodes to attach the same block device. A normal vDisk belongs to one VM; a volume group can be presented to several initiators.
- Bare-metal servers. A physical server has no hypervisor to attach a vDisk through, so iSCSI is the route.
- Storage whose lifecycle differs from the VM. Data that must survive the VM being rebuilt, or be reattached elsewhere, is cleaner as a volume group.
- Large or numerous disks where managing capacity separately from the VM is preferable.
- Container persistent volumes, where Kubernetes workloads consume Nutanix block storage.
[!TIP] Exam discriminator: "more than one host or server must attach the same block device" always points to a volume group. A standard vDisk cannot be shared that way.
Changing vDisk Placement
"Change vDisk placement" means moving a virtual disk from one storage container to another. To understand why anyone would, recall from section 4.1 that policies are set at the container level:
- Replication factor
- Compression
- Deduplication
- Erasure coding
- Reservations
A vDisk inherits the policies of the container it sits in. So if a database VM was provisioned into a container with deduplication enabled and that turns out to be wrong for its workload, the fix is not to change the container — that would affect every other vDisk in it — but to move this vDisk to a container with the right policies.
Common reasons to move a vDisk:
| Reason | Move to a container with… |
|---|---|
| Workload needs stronger protection | RF3 instead of RF2 |
| Deduplication is costing more than it saves | Deduplication disabled |
| Cold archival data should be denser | Erasure coding enabled |
| Data must be separated for compliance or chargeback | A dedicated container |
Live migration across storage containers
The capability that makes this practical is live vDisk migration across storage containers: the disk moves while the virtual machine keeps running. Historically, changing a disk's container meant powering off the VM, moving the data, and reattaching — a maintenance window for what is really a policy change.
With live migration:
- The administrator initiates the migration in Prism, choosing the target container.
- Data is copied to the target container in the background.
- I/O continues to be served throughout.
- When the copy completes, the vDisk is now governed by the target container's policies.
[!IMPORTANT] Do not confuse the three "migrations." VM live migration moves a running VM between hosts — compute. vDisk migration moves a disk between storage containers — policy. Data locality is the automatic background movement of a VM's data to whichever node currently runs it, and requires no administrative action at all.
Configuring Storage for a VM: The Options
Pulling Objective 2.1 together, when adding storage to a VM in Prism you are choosing between:
| Option | Result |
|---|---|
| Allocate on container | A new empty vDisk created in the selected storage container — the normal case |
| Clone from image | A disk created from an Image Service image (section 6.2) |
| Clone from an existing vDisk | A space-efficient copy of another disk |
| Attach a volume group | Block storage presented over iSCSI, shareable and independent of the VM |
And after provisioning, the two adjustments that matter: resize the disk, or change its placement by migrating it to a different container.
A database virtual machine was provisioned into a storage container configured with RF2, but the application owner now requires it to survive two simultaneous node failures. How is this changed with the least disruption?
Two physical servers running a failover cluster need to attach the same block device from the Nutanix cluster. What is used, and how is access controlled?
Which statement correctly distinguishes vDisk migration from VM live migration?