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.)
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. D15C-<volume id>"@ uuid.UUID( "3cca4135- a809-5bb3- af62-275fbfe871 78"), "<target> /<port> /<iqn>" )@
* SR UUID naming convention changed:
** old-style: @"FA15E-
** new-style: @uuid.uuid5(
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 @XenapiLiveMigr ateData@ , 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 @LibvirtLiveMig rateData@ 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 XenapiLiveMigra teData 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' ][*]['connectio n_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:ComputeManag er.check_ can_live_ migrate_ destination( ) nova/compute/ manager. py:ComputeManag er._do_ check_can_ live_migrate_ destination( ) xenapi/ driver. py:XenAPIDriver .check_ can_live_ migrate_ destination( ) xenapi/ vmops.py: VMOps.check_ can_live_ migrate_ destination( ) nova/compute/ manager. py:ComputeManag er.check_ can_live_ migrate_ source( ) xenapi/ driver. py:XenAPIDriver .check_ can_live_ migrate_ source( ) xenapi/ vmops.py: VMOps.check_ can_live_ migrate_ source( ) xenapi/ driver. py:check_ can_live_ migrate_ destination_ cleanup( ) nova/compute/ manager. py:ComputeManag er.live_ migration( ) nova/compute/ manager. py:ComputeManag er._do_ live_migration( ) nova/compute/ manager. py:ComputeManag er.pre_ live_migration( ) xenapi/ driver. py:XenAPIDriver .pre_live_ migration( block_device_ info) xenapi/ vmops.py: VMOps.connect_ block_device_ volumes( block_device_ info) info['block_ device_ mapping' ]: connection_info = block_device_ map['connection _info'] @ xenapi/ volumeops. py:VolumeOps. connect_ volume( connection_ info) xenapi/ volumeops. py:VolumeOps. _attach_ volume( connection_ info) info['data' ]@ xenapi/ volumeops. py:VolumeOps. _connect_ to_volume_ provider( connection_ data) xenapi/ volume_ utils.py: parse_sr_ info(connection _data) volume_ info(connection _data)@ D15C-<volume id>"@ uuid.UUID( "3cca4135- a809-5bb3- af62-275fbfe871 78"), "<target> /<port> /<iqn>" )@ xenapi/ driver. py:XenAPIDriver .live_migration ()
## destination:
### nova/virt/
#### nova/virt/
### source:
#### nova/virt/
##### nova/virt/
## nova/virt/
# source:
## source:
### destination:
#### nova/virt/
##### nova/virt/
###### @for block_device_map in block_device_
###### nova/virt/
####### nova/virt/
######## @connection_data = connection_
######## nova/virt/
######### nova/virt/
########## @params = _parse_
########## create SR UUID
########### old-style: @"FA15E-
########### new-style: @uuid.uuid5(
### nova/virt/