ShapeBlue Migrate v0.6.0 is now available to all ShapeBlue customers who need to migrate from VMware to Apache CloudStack! The key improvement in the new version is that OVERLAY no longer needs the VMware VM powered off. The VM keeps running while the migration prepares, then waits for its cutover policy, the same way Changed Block Tracking (CBT) works. That gives Migrate two warm migration methods instead of one. OVERLAY can now also work from VMFS source storage, and it consolidates its disks automatically after the move.

 

 

OVERLAY Is Now a Warm Migration Method

OVERLAY is the fastest of Migrate’s four transfer methods. It creates a qcow2 overlay on top of the source VMDK and converts in place, so no disk data crosses the network. Until now, the catch was that the source VM had to be powered off before the migration started, so downtime began at the start of the migration instead of at the cutover.

In v0.6.0 the source VM stays up. The migration prepares while the VM runs, then waits in Awaiting Cutover until its cutover policy fires. Downtime happens only at the cutover, and you get OVERLAY’s speed without shutting the workload down early.

That leaves two warm methods to choose from, per VM or per wave. CBT copies data over the network and re-syncs changes. OVERLAY skips the copy entirely when the storage layout allows it.

 

VMFS source storage, via Relocate

OVERLAY’s other limit was storage. It needs the source datastore to be an NFS export that is also mounted in CloudStack as primary storage, which ruled out VMFS.

v0.6.0 adds a relocation step. A VM on VMFS is moved with Storage vMotion, while it keeps running, to the NFS datastore set as the Relocate via target in its datastore mapping. If the migration fails or is cancelled, or once a completed migration has been consolidated, Relocate back returns the VM to its original datastores on request.

A pre-flight check reports every problem with the target, the vCenter privileges and CloudStack’s backing-file setting before anything moves, and a Storage vMotions in flight setting limits how many relocations run at once. vSAN and VVol are expected to work the same way but are not yet tested.

 

Automatic Disk Consolidation

After an OVERLAY import, the migrated volume is a qcow2 file backed by the source VMDK. Until that chain is collapsed, the source datastore stays in use and the source VM has to stay powered off and untouched.

v0.6.0 collapses the chain for you. The new OVERLAY chain consolidation setting runs whether the migrated VM is running or stopped in CloudStack, and a running VM takes no extra downtime for it. When it finishes, the source VM and its files are released.

Each finished OVERLAY migration also gets its own Consolidate button, and outstanding consolidations are flagged so they don’t get forgotten. A bandwidth cap limits the load on the NFS export while they run. Consolidations use their own lane on each worker, so they don’t take a migration slot or hold up a cutover.

 

Warm Migration Without VDDK

OVERLAY has never depended on VMware’s VDDK library. That mattered less while it required a powered-off VM, because an estate that couldn’t get VDDK was left with cold migrations only.

The last two releases changed that. v0.5.0 added a direct NFS read path for CBT, which removed VDDK from warm migrations on NFS source storage. v0.6.0 makes OVERLAY warm and extends it to VMFS. An estate without VDDK now has a warm migration route on either NFS or VMFS.

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

 

Ceph RBD as a Migration Destination

CBT and VDDK migrations can now write directly to Ceph RBD primary storage. Migrate detects RBD support from CloudStack and writes converted disks straight to RBD images. Until support is detected, RBD pools are shown as disabled, along with the reason.

The target needs CloudStack 4.22.2 or later, and the workers need qemu’s RDB driver and the nbd kernel module. The worker installer adds both where it can. OVERLAY and OVF still write to NFS primary storage only.

 

Choosing How Guest IP Address are Handled

Until now, keeping a guest’s network identity meant injecting a static configuration into the guest. That works, but many estates don’t want addressing managed inside the guest.

v0.6.0 adds a Default IP Handling Mode, which you can override per wave and per VM. It has three options:

• Inject the static configuration into the guest, as before
• Have CloudStack assign the same IP and leave the guest on DHCP
• Keep the source MAC address and let DHCP hand back the same IP

If you run your own DHCP or IPAM, you no longer have to work around guest-level injection.

One thing to check after upgrading: guest IP and MAC preservation is now off by default. If your deployment relied on it, enable it in Settings and set a default temporary import network.

What This Means for a Migration Project

• The fastest method no longer means downtime up front
• VMFS estates can use OVERLAY, and the relocation can be reversed
• No manual clean-up after an OVERLAY wave
• Ceph RBD can be a target for CBT and VDDK
• IP handling that fits how your network already works

 

Fixes from Real Migrations

v0.6.0 also includes fixes for issues found in customer deployments and in testing on real infrastructure. Two of them concern data integrity in CBT. A copy could miss recent writes if a VMware snapshot or an unconsolidated delta was in the disk chain during a direct NFS read, and a delta or final pass could keep data the guest had since zeroed.

Task handling is also more reliable. A worker that stalled briefly could have its task picked up by a second worker, which created a duplicate VM in CloudStack. A cutover’s final sync could also get stuck behind routine deltas from other VMs. All of these are fixed, and the full list is in the release notes.

 

Availability

ShapeBlue Migrate v0.6.0 is available now to all ShapeBlue customers. To learn more or to talk through your VMware to Apache CloudStack migration, contact us at info@shapeblue.com.

 

FAQ about ShapeBlue Migrate v0.6.0

Does OVERLAY still need the source VM powered off?
No. A running VM stays up and waits in Awaiting Cutover until its cutover policy fires, the same as CBT. After the cutover, the source VM only has to stay powered off until its disk chain has been consolidated.

Can OVERLAY use VMFS datastores now?
Yes. The VM is moved with Storage vMotion, while still running, to the NFS datastore set as the Relocate via target. It can be moved back if the migration fails or is cancelled.

Do I still need to clean up OVERLAY disks by hand?
No. OVERLAY chain consolidation collapses the backing chain whether the migrated VM is running or stopped, with no extra downtime for a running VM. Anything outstanding can be handled with the per-VM Consolidate button.

Which methods can write to Ceph RBD?
CBT and VDDK. OVERLAY and OVF remain NFS-only, and the target needs CloudStack 4.22.2 or later.

What happened to the Unregister OVERLAY Source VM setting?
Consolidation replaces it and releases the source VM and its files completely. If you used that setting, configure OVERLAY chain consolidation after upgrading.

How do I get v0.6.0?
It’s available to all ShapeBlue customers and upgrades in place over v0.5.0.