Share:

ShapeBlue Migrate v0.5.0: Direct NFS Reads for Changed Block Tracking

ShapeBlue Migrate v0.5.0 is now available to all ShapeBlue customers, and it upgrades in place over v0.4.0. 

The main addition is a new read path for Changed Block Tracking. The migration worker can now read source disks straight from the NFS datastore that holds them, shortening the transfer path and removing the VMware VDDK library from the warm-migration workflow. 

Direct NFS Reads for Changed Block Tracking 

Changed Block Tracking is the warm-migration method in Migrate, the one behind delta syncs and a short, scheduled cutover. Until now it read every block through an NFC session on the ESXi host, using the VDDK library on the worker. 

v0.5.0 adds a second way to do that read. The worker mounts the source datastore’s NFS export read-only and reads each disk directly, with no VDDK library involved and no ESXi host in the middle. The full workflow is unchanged: full copy, delta passes, final sync and planned cutover. 

Two things follow from the shorter path. The worker pulls from the NFS server over its own storage network, so where the read was the bottleneck, migrations get faster. And because the library is out of the path, warm migration on NFS-backed estates no longer depends on obtaining and maintaining VDDK on every worker. 

Obtaining VDDK has also become harder for some estates, which we covered in a separate post on the Broadcom download pages. 

The option is opt-in and set per migration, and anything it cannot serve falls back to the VDDK read automatically. Existing waves keep running as they are. 

 

 

The worker reads the flat VMDK straight off the NFS mount - no VDDK, no NFC session on ESXi
The worker reads the flat VMDK straight off the NFS mount – no VDDK, no NFC session on ESXi.

How It Fits with the Other Transfer Methods 

Migrate offers four disk-transfer methods, selectable per VM or per wave. OVERLAY and OVF both require the source VM to be powered off. Changed Block Tracking is the one that keeps the source running while data moves, which is what makes a short cutover window possible. 

Direct NFS reads apply to that method only, and to estates whose source datastores are NFS exports reachable from the worker. Everything else continues to work exactly as it did in v0.4.0. 

One checkbox turns it on - no VDDK library required, automatic fallback for anything it can't serve
One checkbox turns it on – no VDDK library required, automatic fallback for anything it can’t serve

What This Changes for a Migration Project 

  • Faster delta syncs where the NFC session on the ESXi host was the bottleneck 
  • Less load on the ESXi hosts during long copies, since the read no longer passes through them 
  • Fewer moving parts on each migration worker for NFS-backed estates 
  • No change required to existing waves, because the new path is opt-in with automatic fallback 

Automatic Source VM Unregister After OVERLAY Imports 

An OVERLAY-migrated disk is a qcow2 backed by the source VMDK, so powering the source VM back on or snapshotting it corrupts the migrated disk. v0.5.0 can now remove the source VM from vCenter inventory automatically once its import succeeds. It is an unregister, not a delete, so the files stay on the datastore and the VM can be registered again if needed. 

Fixes from Real Migrations 

v0.5.0 is primarily a bug-fix release, and most of it came from customer-reported issues and testing on real infrastructure since v0.4.0 shipped: CBT imports landing in the wrong CloudStack account, long syncs losing their vCenter session mid-migration, VM renames in vCenter breaking discovery for an entire source, imports failing on names containing a space, and a set of wave and group planning corrections. The full list is in the release notes. 

Availability 

ShapeBlue Migrate v0.5.0 is available to all ShapeBlue customers and upgrades in place over v0.4.0. 

Contact ShapeBlue to learn more about ShapeBlue Migrate or to discuss your VMware to Apache CloudStack migration requirements at info@shapeblue.com! 

FAQ about ShapeBlue Migrate v0.5.0 

What do I need to use direct NFS reads? 

The source datastore has to be an NFS export that the migration worker can mount read-only. The option is then selected per migration. 

Does it change how warm migration works? 

No. Full copy, delta passes, final sync and planned cutover are the same. Only the way the worker reads the source disk changes. 

What happens if a disk cannot be read over NFS? 

Migrate falls back to the VDDK read automatically for that disk. 

Do I have to change my existing migration waves? 

No. The new read path is opt-in, and waves configured in v0.4.0 keep running unchanged. 

How do I get v0.5.0? 

It is available to all ShapeBlue customers and upgrades are in place over v0.4.0. 

Share:

Related Posts:

ShapeBlue

Discover the new features: CloudStack DNS Framework, Alarms and Monitoring Framework, Modernised CLVM support, Async Job Management, VPC Conserve Mode, and many more.