A desktop rebalance operation evenly redistributes linked-clone desktops among available logical drives. It saves storage space on overloaded drives and ensures that no drives are underused.

When you create large linked-clone desktop pools and use multiple Logical Unit Numbers (LUNs), the space might not be used efficiently if the initial sizing was inaccurate. If you set an aggressive storage overcommit level, the linked clones can grow quickly and consume all the free space on the datastore.

When the virtual machines use 95% of the space on the datastore, View Manager generates a warning log entry. At 99% usage, vSphere suspends every virtual machine on the datastore.

The rebalance also refreshes the linked clones, reducing the size of their OS disks. It does not affect View Composer persistent disks.

Apply these guidelines to desktop rebalances:

You can rebalance dedicated-assignment and floating-assignment pools.

You can rebalance selected linked clones or all clones in a pool.

You can rebalance a desktop pool on demand or as a scheduled event.

You can schedule only one rebalance operation at a time for a given set of linked clones. If you start a rebalance operation immediately, the operation overwrites any previously scheduled task.

You can schedule multiple rebalance operations if they affect different linked clones.

Before you schedule a new rebalance operation, you must cancel any previously scheduled task.

You can only rebalance desktops in the Available, Error, or Customizing state with no schedules or pending cancellations.

As a best practice, do not mix linked-clone virtual machines with other types of virtual machines on the same datastore. This way View Composer can rebalance all the virtual machines on the datastore.

If you edit a pool and change the host or cluster and the datastores on which linked clones are stored, you can only rebalance the linked clones if the newly selected host or cluster has full access to both the original and the new datastores. All hosts in the new cluster must have access to the original and new datastores.

For example, you might create a linked-clone pool on a standalone host and select a local datastore to store the clones. If you edit the pool and select a cluster and a shared datastore, a rebalance operation will fail because the hosts in the cluster cannot access the original, local datastore.