Migrating Boot Volumes
Cirrus Migrate Cloud (CMC) can be used by migrating boot volumes (os volumes) on all supported windows and linux operating systems. Many of the CMC functionalities benefits boot volume migration as well.
Note: Cirrus Migration Cloud Software Version 3.0.0+ is required
This includes:
Auto Destination Allocation
iQoS
Local / Remote Migration
Automatic resynchronization
Migration Automation (Pre/Post Migration Actions)
....and more.
Before proceeding, you MUST ensure that you possess knowledge and ability to perform all necessary changes to your host (or other infrastructure) so that your hosts will boot from the migrated volumes.
These configuration changes requirements vary depending on specific system configurations. They may include:
Filesystem mount point configuration
BIOS (or other boot system) settings
Volume Assignment settings (such as some SAN boot configurations where the lun number for booting is fixed)
Migration sessions for boot volumes can be created just like any other migration session. During Migration Session Creation, “Step 2. Select Migration Volume Type” allows selection of migration for Boot Volumes:
Follow the rest of the steps of the wizard to pair the source and destination boot volumes. It is highly recommended to use a separate migration session for OS disks, and another session for data disks.
Cutting over a boot volume by definition requires a reboot. Therefore, cMotion™ is not supported for migration sessions that have boot volumes included. To migrate the data volumes without downtime using cMotion™, create another migration sessions with just the data volumes.
Once a session is created, it will start synchronizing. iQoS can be used to minimize source volume performance impact. All new changes to the boot volume will be tracked and migrated in subsequent synchronization pass.
Note: it is recommended not to select “Relentless” mode for the iQoS. For OS disks with limited IO, the “Aggressive” mode is usually good enough.
Cutting over a boot volume by definition requires a reboot. Therefore, cMotion™ is not supported for migration sessions that have boot volumes included.
For migration sessions involving boot volumes, you will see an action called "Perform Final Cutover". This action will perform one FINAL synchronization pass to establish a crash-consistent image on the destination volume and remove disk scrambling on the destination volumes so that the destination volume will be bootable in the next boot. Also note that the source disks are never scrambled for OS disk migration sessions. Therefore, it is important to perform the removal of the source disk after a shutdown as the very next step. Do not keep the system at the state where both the source and destination are visible to the host otherwise any accidental reboot in this state will result in unpredictable usage of the source or the destination volumes given that they both are identical and with the exact same volume UUID.
If you need to make changes to the boot volume that is intended to be effective after the cutover to the newly migrated disks, you must make the changes BEFORE the “Finalize Cutover” action below, otherwise your changes will not be synced.
WARNING! Before performing final cutover of OS disks, host applications should be stopped, any adjustments to boot configurations must be performed, and filesystem caches must be flushed. Think of the Final Cutover action as taking a snapshot using the destination disks. Changes to the volumes made after Final Cutover will not be sync’d to the destination disks.
Note: You must have less than 1.00GB of outstanding changed data before final cutover can be performed. Otherwise, you must first separately trigger a synchronization pass.
Once final cutover is completed, the migration session will go into COMPLETED state. The following actions must be done immediately:.
For SAN Boots or Blade Servers, reconfigure host to boot using the Destination disks
Shut down source host (power off)
Remove source boot volume (remove from VMWare, detach, unzone, change LUN mask, etc.)
For SAN Booting, modify the FC or iSCSI HBA settings to boot using the Destination disks
Double check that upon next power-on, the system will no longer see the Source boot disks.
Once final cutover is performed, both source and destination will become bootable. As a result, it is vitally important to quickly switch over to new volume by shutting down and removing source volume.
Boot volumes can be migrated remotely as well. Migration procedure is identical, with the exception that when cutover, the source host should, after triggering “Final Cutover” and before shutdown:
-Reconfigure the IP address, hostname, application settings etc. so that it will no longer be playing the role that is to be replaced by the replacement host.
The destination host should be powered on after the source host is shutdown.
When migrating boot volumes, it is recommended that you:
Migrate the boot volume and data volumes in separate migration sessions to allow the use of cMotion™ and separate cutover schedule.
It is recommended to use a separate migration to sync up the data volumes first, and then create the migration session for the boot volume.
Just prior to triggering Final Cutover, stop any host application. Perform a ‘sudo sync’ to flush any cached disk writes. This will improve the state of the captured boot disk image.
Perform the Final Cutover of the Boot volume migration session when you are ready to shutdown and reboot. For host to host migration where the new host replaces the current host, make changes to the host such that the host name, IP address, application settings, etc are all done prior to shutdown, such that upon the next start up, it no longer interferes with the replacement host.
For local migration, after shutdown, detach/remove/unzone the source volumes so that the new boot will only have the newly migrated destination volumes. This is important because the source volumes are identical to the destination volumes, and so if booting with both sets of volumes, the OS boot process will not guarantee to only use the new volume for all the OS mount points.
Note: Cirrus Migration Cloud Software Version 3.0.0+ is required
This includes:
Auto Destination Allocation
iQoS
Local / Remote Migration
Automatic resynchronization
Migration Automation (Pre/Post Migration Actions)
....and more.
Requirements
Before proceeding, you MUST ensure that you possess knowledge and ability to perform all necessary changes to your host (or other infrastructure) so that your hosts will boot from the migrated volumes.
These configuration changes requirements vary depending on specific system configurations. They may include:
Filesystem mount point configuration
BIOS (or other boot system) settings
Volume Assignment settings (such as some SAN boot configurations where the lun number for booting is fixed)
How-To Migrate Boot Volumes
Creating Migration Session
Migration sessions for boot volumes can be created just like any other migration session. During Migration Session Creation, “Step 2. Select Migration Volume Type” allows selection of migration for Boot Volumes:
Follow the rest of the steps of the wizard to pair the source and destination boot volumes. It is highly recommended to use a separate migration session for OS disks, and another session for data disks.
Cutting over a boot volume by definition requires a reboot. Therefore, cMotion™ is not supported for migration sessions that have boot volumes included. To migrate the data volumes without downtime using cMotion™, create another migration sessions with just the data volumes.
Data Synchronization
Once a session is created, it will start synchronizing. iQoS can be used to minimize source volume performance impact. All new changes to the boot volume will be tracked and migrated in subsequent synchronization pass.
Note: it is recommended not to select “Relentless” mode for the iQoS. For OS disks with limited IO, the “Aggressive” mode is usually good enough.
Final Cutover
Cutting over a boot volume by definition requires a reboot. Therefore, cMotion™ is not supported for migration sessions that have boot volumes included.
For migration sessions involving boot volumes, you will see an action called "Perform Final Cutover". This action will perform one FINAL synchronization pass to establish a crash-consistent image on the destination volume and remove disk scrambling on the destination volumes so that the destination volume will be bootable in the next boot. Also note that the source disks are never scrambled for OS disk migration sessions. Therefore, it is important to perform the removal of the source disk after a shutdown as the very next step. Do not keep the system at the state where both the source and destination are visible to the host otherwise any accidental reboot in this state will result in unpredictable usage of the source or the destination volumes given that they both are identical and with the exact same volume UUID.
If you need to make changes to the boot volume that is intended to be effective after the cutover to the newly migrated disks, you must make the changes BEFORE the “Finalize Cutover” action below, otherwise your changes will not be synced.
WARNING! Before performing final cutover of OS disks, host applications should be stopped, any adjustments to boot configurations must be performed, and filesystem caches must be flushed. Think of the Final Cutover action as taking a snapshot using the destination disks. Changes to the volumes made after Final Cutover will not be sync’d to the destination disks.
Note: You must have less than 1.00GB of outstanding changed data before final cutover can be performed. Otherwise, you must first separately trigger a synchronization pass.
Completing Migration
Once final cutover is completed, the migration session will go into COMPLETED state. The following actions must be done immediately:.
For SAN Boots or Blade Servers, reconfigure host to boot using the Destination disks
Shut down source host (power off)
Remove source boot volume (remove from VMWare, detach, unzone, change LUN mask, etc.)
For SAN Booting, modify the FC or iSCSI HBA settings to boot using the Destination disks
Double check that upon next power-on, the system will no longer see the Source boot disks.
Once final cutover is performed, both source and destination will become bootable. As a result, it is vitally important to quickly switch over to new volume by shutting down and removing source volume.
Remote Migration
Boot volumes can be migrated remotely as well. Migration procedure is identical, with the exception that when cutover, the source host should, after triggering “Final Cutover” and before shutdown:
-Reconfigure the IP address, hostname, application settings etc. so that it will no longer be playing the role that is to be replaced by the replacement host.
The destination host should be powered on after the source host is shutdown.
Summary of Best Practices
When migrating boot volumes, it is recommended that you:
Migrate the boot volume and data volumes in separate migration sessions to allow the use of cMotion™ and separate cutover schedule.
It is recommended to use a separate migration to sync up the data volumes first, and then create the migration session for the boot volume.
Just prior to triggering Final Cutover, stop any host application. Perform a ‘sudo sync’ to flush any cached disk writes. This will improve the state of the captured boot disk image.
Perform the Final Cutover of the Boot volume migration session when you are ready to shutdown and reboot. For host to host migration where the new host replaces the current host, make changes to the host such that the host name, IP address, application settings, etc are all done prior to shutdown, such that upon the next start up, it no longer interferes with the replacement host.
For local migration, after shutdown, detach/remove/unzone the source volumes so that the new boot will only have the newly migrated destination volumes. This is important because the source volumes are identical to the destination volumes, and so if booting with both sets of volumes, the OS boot process will not guarantee to only use the new volume for all the OS mount points.
Updated on: 05/08/2022
Thank you!