# The migration time improvement **URL:** \ **Category:** Integration Support\ **Created:** [January 6, 2016, 8:56pm UTC](https://forum.opennebula.io/t/the-migration-time-improvement/1660 "2016-01-06T20:56:30Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![soufian](https://avatars.discourse-cdn.com/v4/letter/s/77aa72/32.png) [@soufian](https://forum.opennebula.io/u/soufian)\ **Post date:** [January 6, 2016, 8:56pm UTC](https://forum.opennebula.io/t/the-migration-time-improvement/1660/1 "2016-01-06T20:56:30Z")
Hello, I work on a live migration Improvement project using OpenNebula solution, for now the idea that I have is to analyze the migration scripts, see the files sent over the network when migrating, try to compress when sending or try to change the method of compression if the solution already can compress the files before sending them. If you have documents that can help me or track to follow, thank you for sharing ---
**Author:** ![cmartin](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/cmartin/32/4278_2.png) [@cmartin](https://forum.opennebula.io/u/cmartin)\ **Post date:** [January 7, 2016, 10:19am UTC](https://forum.opennebula.io/t/the-migration-time-improvement/1660/2 "2016-01-07T10:19:24Z")
Hi, Opennebula uses the migrate script of the vmm actions to initiate the live migrations. Take a look at the vmm drivers, located at /var/lib/one/remotes/vmm/ More info here: [http://docs.opennebula.org/4.14/integration/infrastructure\_integration/devel-vmm.html](http://docs.opennebula.org/4.14/integration/infrastructure_integration/devel-vmm.html) > **[OpenNebula/one](https://github.com/OpenNebula/one/tree/master/src/vmm_mad/remotes)** > > The open source Cloud Management Platform developed for the Enterprise :rocket: - OpenNebula/one ---
**Author:** ![atodorov\_storpool](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/atodorov_storpool/32/5327_2.png) [@atodorov\_storpool](https://forum.opennebula.io/u/atodorov_storpool)\ **Post date:** [January 7, 2016, 8:53pm UTC](https://forum.opennebula.io/t/the-migration-time-improvement/1660/3 "2016-01-07T20:53:37Z")
Hi, IMO there are different places that can be improved. First of all, the disks of the VM should be on a “shared” datastore because the disks images must be accessible from both source and destination hosts. Before VMM\_MAD/migrate is called the TM\_MAD/premigrate script is called to handle disks. At this stage the speed depend on the exact TM\_MAD driver used for the disk images and the number of the attached disks. Then the VMM\_MAD/migrate is called on the source host. The migration is done with libvirt via qemu+ssh protocol so there is not much space for improvements. If you have faster network available(10G,40G), you can tweak the VMM\_MAD/migrate to migrate over the faster network(we have a variant that is in our pipeline to push it soon to our addon). Another option is to try some different [migration](https://libvirt.org/migration.html) scenarios. After successful VM migration TM\_MAD/postmigrate script is called to cleanup the source host. By default TM\_MAD/ssh has no live migration enabled because it is not shared and the volatile disks that are located on the SYSTEM datastore are killer to transfer over the network. In the VM home located in the SYSTEM datastore there are 3 of 4 files that are bigger and need special handling: 1. persistent/non-persistent disk images 2. volatile disk images 3. the contextualization ISO disk image 4. the checkpoint file (not related to the live migration) if the TM\_MAD we supports both SYSTEM and IMAGE datastores and can provide fast access for persistent/nonpersistent, volatile and context disk images to both source and the destination hosts there is a chance to have really fast live migration. As our [addon-storpool](https://github.com/OpenNebula/addon-storpool) support both SYSTEM and IMAGE datastores the VM migration is very fast. Even the “cold” migration is faster because only the deployment XML of the VM is transferred over the network. This is because we are extending the TM\_MAD/ssh and TM\_MAD/shared with our pre/postmigrate scripts that handle all of the bigger files in the VM home (the checkpoint import/export to storpool block device is WIP in the “next” branch). Take a look at our [addon](https://github.com/OpenNebula/addon-storpool) and use the [README.md](http://README.md) file (or the [install.sh](http://install.sh) file but here is a mess to handle upgrades) as a guide where/how we are integrating with the other modules of OpenNebula. I’ll be happy to answer any technical questions If something is not clear. Kind Regards, Anton Todorov ---
**Author:** ![atodorov\_storpool](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/atodorov_storpool/32/5327_2.png) [@atodorov\_storpool](https://forum.opennebula.io/u/atodorov_storpool)\ **Post date:** [January 14, 2016, 5:40pm UTC](https://forum.opennebula.io/t/the-migration-time-improvement/1660/4 "2016-01-14T17:40:54Z")
Hi @soufian @cmartin, Finally I have some time to play with the VM migrations. With a little tweak I’ve managed to live migrate a VM using 10G interface. The migration time (as expected) is almost 10x faster. My tests shows that is is not destructive and by default the scripts will behave as usual. You can find attached a patch file[00-vmm\_kvm\_migrate.patch](https://canada1.discourse-cdn.com/flex031/uploads/opennebula/original/2X/1/1f7456dde22c22c10ac1be8f60ce87c6045f9d26.patch) (848 Bytes) The patch is introducing extra argument for the migration interface which is the default dest\_host but with appended “optional” variable `DEST_HOST_APPEND` Here is simple followup how to enable the change ```auto # on each host: echo "IP_OF_THE_10G_IFACE1 hostname1-10g1" >>/etc/hosts echo "IP_OF_THE_10G_IFACE2 hostname2-10g1" >>/etc/hosts echo "IP_OF_THE_10G_IFACE3 hostname3-10g1" >>/etc/hosts # add the append to the kvmrc echo "DEST_HOST_APPEND=\"-10g1\"" >>/var/lib/one/remotes/vmm/kvm/kvmrc # assuming the patch is in the user's home cd /var/lib/one/remotes/vmm/kvm/ patch -p0 < ~/00-vmm_kvm_migrate.patch # sync the changes su - oneadmin onehost sync --force ``` * * * Carlos, i’ve spot a little bug in the migrate\_local script [here](https://github.com/OpenNebula/one/pull/82) is the pull request against the current master branch. Kind Regards, Anton Todorov ---
**Author:** ![atodorov\_storpool](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/atodorov_storpool/32/5327_2.png) [@atodorov\_storpool](https://forum.opennebula.io/u/atodorov_storpool)\ **Post date:** [January 15, 2016, 9:24am UTC](https://forum.opennebula.io/t/the-migration-time-improvement/1660/5 "2016-01-15T09:24:41Z")
Hi, I’ve added the issues to the dev portal too: - [bug4291](http://dev.opennebula.org/issues/4291) - missing MIGRATE\_OPTIONS variable in vmm/kvm/migrate\_live - [feature4292](http://dev.opennebula.org/issues/4292) - add possibility to live migrate via another interface Cheers, Anton Todorov