VMware-vSphere5.5-Platform-Whats-New(13)

vSphere 5.5最新资料

What’s New in VMware vSphere 5.5 Platform PDL AutoRemove occurs only if there are no open handles left on the device. The auto-remove takes place when the last handle on the device closes. If the device recovers, or if it is readded after having been inadvertently removed, it will be treated as a new device.

vSphere Replication Interoperability

In vSphere 5.0, there were interoperability concerns with VMware vSphere Replication and VMware vSphere Storage vMotion®, as well as with VMware vSphere Storage DRS™. There were considerations to be made at both the primary site and the replica site.

At the primary site, because of how vSphere Replication works, there are two separate cases of support for vSphere Storage vMotion and vSphere Storage DRS to be considered:

• Moving a subset of the virtual machine’s disks

• Moving the virtual machine’s home directory

This works fine in the first case—moving a subset of the virtual machine’s disks with vSphere Storage vMotion or vSphere Storage DRS. From the vSphere Replication perspective, the vSphere Storage vMotion migration is a “fast suspend/resume” operation, which vSphere Replication handles well.

The second case—a vSphere Storage vMotion migration of a virtual machine’s home directory—creates the issue with primary site migrations. In this case, the vSphere Replication persistent state files (.psf) are deleted rather than migrated. vSphere Replication detects this as a power-off operation, followed by a power-on of the virtual machine without the “.psf” files. This triggers a vSphere Replication “full sync,” wherein the disk contents are read and checksummed on each side, a fairly expensive and time-consuming task. vSphere 5.5 addresses

this scenario.

At the primary site, migrations now move the persistent state files that contain pointers to the changed

blocks along with the VMDKs in the virtual machine’s home directory, thereby removing the need for a full synchronization. This means that replicated virtual machines can now be moved between datastores, by vSphere Storage vMotion or vSphere Storage DRS, without incurring a penalty on the replication. The retention of the .psf means that the virtual machine can be brought to the new datastore or directory while retaining its current replication data and can continue with the procedure and with the “fast suspend/resume” operation of moving an individual VMDK.

At the replica site, the interaction is less complicated because vSphere Storage vMotion is not supported for the replicated disks. vSphere Storage DRS cannot detect the replica disks: They are simply “disks”—there is no “virtual machine.” While the .vmx file describing the virtual machine is there, the replicated disks are not actually attached until test or failover occurs. Therefore, vSphere Storage DRS cannot move these disks because it only detects registered virtual machines. This means that there are no low-level interoperability problems, but there is a high-level one because it is preferable that vSphere Storage DRS detect the replica disks and be able to move them out of the way if a datastore is filling up at the replica site. This scenario remains the same in the vSphere 5.5 release. With vSphere Replication, moving the target virtual machines is accomplished by manually pausing—not “stopping,” which deletes the replica VMDK—replication; cloning the VMDK, using VMware vSphere Command-Line Interface, into another directory; manually reconfiguring vSphere Replication to point to the new target; waiting for it to complete a full sync; and then deleting the old replica files. vSphere Replication Multi-Point-in-Time (MPIT) Snapshot Retention

vSphere Replication through vSphere 5.1 worked by creating a redo log on the disk at the target location. When a replication was taking place, the vSphere Replication appliance received the changed blocks from the source host and immediately wrote them to the redo log on the target disk.

Because any given replication has a fixed size according to the number of changed blocks, vSphere Replication could determine when the complete replication bundle (the “lightweight delta”) had been received. Only then did it commit the redo log to the target VMDK file.

T E C H N I C A L W H I T E P A P E R/13