live migrations are broken for any deployer using xen with pre-mitaka instances, so a configuration option is insufficient (as i see it).

the requirement: maintain the SR and VDI UUIDs between source and destination during live-migration

* VDI UUID naming convention appears to be unchanged.
* SR UUID naming convention changed:
** old-style: @"FA15E-D15C-<volume id>"@
** new-style: @uuid.uuid5(uuid.UUID("3cca4135-a809-5bb3-af62-275fbfe87178"), "<target>/<port>/<iqn>")@

so the derived requirements are:

# determine whether the source has an old or new-style named SR
# pass that determination to the destination for use when it creates its SR name

because this is all specific to the XenAPI virt driver and the destination creates the SR name in @pre_live_migration()@, the determination will have to be before then in @check_can_live_migrate_source()@ (ie the only place where the source's XenAPI virt driver is called beforehand).  this is somewhat of a hack because ideally this would be done in @pre_live_migration@ on the source, which doesn't exist (@pre_live_migration()@ is only done on the destination) and this isn't really "checking if the source can live-migrate" (ie @check_can_live_migrate_source()@).

to pass this naming convention determination from source to destination, a determination that has to be done for all volumes attached to an instance (because, correct me if i'm wrong, but the instance could be created pre-mitaka with an old-style-SR volume, but then an additional volume added in mitaka with a new-style SR volume) so a @sr_uuid_naming_convention_map@ mirroring @block_device_mapping@ needs to be added to @XenapiLiveMigrateData@, bumping it's version to 1.0, and adding @obj_make_compatible()@ to it (handling the new @sr_uuid_naming_convention_map@ attribute by dropping it like how @LibvirtLiveMigrateData@ handles @target_connect_addr@ which was added in its version bump from 1.0 to 1.1).

so @sr_uuid_naming_convention_map@ will be passed from source to destination in XenapiLiveMigrateData and the destination can pass it down from @pre_live_migration()@ to @parse_sr_info()@ by way of adding it to @block_device_info['block_device_mapping'][*]['connection_info']['data']@ or by modifying all 5 interfaces called on the way down to @parse_sr_info()@ to pass it separate from block_device_info data.

still need to think about the source side and how exactly to mechanize determining the naming convention style.  (well, obviously look at the SR uuids and if they start with "FA15E-D15C-" then it's old style.)

supporting documentation:

live-migration call-tree

# destination:nova/compute/manager.py:ComputeManager.check_can_live_migrate_destination()
## destination:nova/compute/manager.py:ComputeManager._do_check_can_live_migrate_destination()
### nova/virt/xenapi/driver.py:XenAPIDriver.check_can_live_migrate_destination()
#### nova/virt/xenapi/vmops.py:VMOps.check_can_live_migrate_destination()
### source:nova/compute/manager.py:ComputeManager.check_can_live_migrate_source()
#### nova/virt/xenapi/driver.py:XenAPIDriver.check_can_live_migrate_source()
##### nova/virt/xenapi/vmops.py:VMOps.check_can_live_migrate_source()
## nova/virt/xenapi/driver.py:check_can_live_migrate_destination_cleanup()
# source:nova/compute/manager.py:ComputeManager.live_migration()
## source:nova/compute/manager.py:ComputeManager._do_live_migration()
### destination:nova/compute/manager.py:ComputeManager.pre_live_migration()
#### nova/virt/xenapi/driver.py:XenAPIDriver.pre_live_migration(block_device_info)
##### nova/virt/xenapi/vmops.py:VMOps.connect_block_device_volumes(block_device_info)
###### @for block_device_map in block_device_info['block_device_mapping']: connection_info = block_device_map['connection_info']@
###### nova/virt/xenapi/volumeops.py:VolumeOps.connect_volume(connection_info)
####### nova/virt/xenapi/volumeops.py:VolumeOps._attach_volume(connection_info)
######## @connection_data = connection_info['data']@
######## nova/virt/xenapi/volumeops.py:VolumeOps._connect_to_volume_provider(connection_data)
######### nova/virt/xenapi/volume_utils.py:parse_sr_info(connection_data)
########## @params = _parse_volume_info(connection_data)@
########## create SR UUID
########### old-style: @"FA15E-D15C-<volume id>"@
########### new-style: @uuid.uuid5(uuid.UUID("3cca4135-a809-5bb3-af62-275fbfe87178"), "<target>/<port>/<iqn>")@
### nova/virt/xenapi/driver.py:XenAPIDriver.live_migration()