Volume migration improvement

As we discussed in one design session for Liberty, there are several work items to do in order to make the current migration more stable and robust. The detailed information can be found via https://etherpad.openstack.org/p/volume-migration-improvement.

The work items can be summarized as below, and I would like to implement them for L:
1) Volume state:

    *Volume status should indicate the progress of the migration, not just migration_status to indicate. It is very confusing that the status of the volume is left ‘available’ and ‘in-use’ during migration. Status should be set to "migrating" during migration. When it is over, set it back to its original status.

    *Return message for the cinder client:

    If the migration command is issued, the user should receive a message from the cinderclient saying either this migration won't proceed because of this or that, or your requested will be processed.

    *Destination volume necessary to be seen by the user? additional flag keep it somewhere in the table

    The target volume is created on the target host. It can be seen by the user via "cinder list", but the user actually cannot do nothing to it. It will finally go away no matter the migration is going to succeed or fail. IMO, not necessary to see the destination volume in cinder list.

    *Error state back: how do we know it is success or fail.
    add a 'get_migration_status' command that takes a volume name and returns the status of the last migration.

2) Proposal to go through the notification system perhaps?

    This is a problem that all the projects are facing right now.

3) Volume status recovery and progress indication:
 Migration could fail at any step, it is good to have the volume back to the original state automatically. Otherwise, we will suffering from "unable to do anything to the volume", e.g. unable to delete a volume with migration_status "completing". migration_status can be used to record the status of the previous migration status. 'get_migration_status' command is used to query the status of the migration. "error" means it failed for the previous time. "success" means it succeeded. "null" means no migration is done before. The status of the volume should be either in-use or available.

Progress indication:
dd command: we can use "sudo kill -USR1 [dd process]" to check the percentage of the data transferred. The progress can be put in log information.
driver specific migration: need to take one driver like Storwize V7000 as an example to see if it supports progress status of the migration.

4) Efficient volume copy:

    It sounds like sparse DD resolves the performance issues in some/or many cases.

    Need to better understand the options here.

    doing small blocksize copies will be effective at discarding, but slow in copying. large blocksizes would be smaller, but will keep more zeroes.

    or does the dd option check individual 4kB blocks before writing?
Related BP link: https://blueprints.launchpad.net/cinder/+spec/efficient-volume-copy-for-cinder-assisted-migration