Looking at the nova.virt.libvirt.driver.pre_live_migration() method, I see it's connecting to a volume and the connection_info dictionary is updated in the nova.virt.libvirt.volume code, but I don't see where that connection_info dict comes back to the virt driver's pre_live_migration method and persists the change to the database.
This is where pre_live_migration() connects the volume:
That change never gets persisted back to the block_device_mapping table for the bdm instance, but we've connected the volume potentially on another host so if live migration fails and we never rollback the volume connection_info to the source host (before pre_live_migration), and reboot the instance, then the bdm will be recreated from what's in the database which will be wrong.
I'm trying to sort this out a bit.
Looking at the nova.virt. libvirt. driver. pre_live_ migration( ) method, I see it's connecting to a volume and the connection_info dictionary is updated in the nova.virt. libvirt. volume code, but I don't see where that connection_info dict comes back to the virt driver's pre_live_migration method and persists the change to the database.
This is where pre_live_ migration( ) connects the volume:
http:// git.openstack. org/cgit/ openstack/ nova/tree/ nova/virt/ libvirt/ driver. py?id=2015. 1.0#n5813
Let's assume we're using the LibvirtISCSIVol umeDriver volume driver, the connect_volume method in there will update the connection_info dict here:
http:// git.openstack. org/cgit/ openstack/ nova/tree/ nova/virt/ libvirt/ volume. py?id=2015. 1.0#n483
That change never gets persisted back to the block_device_ mapping table for the bdm instance, but we've connected the volume potentially on another host so if live migration fails and we never rollback the volume connection_info to the source host (before pre_live_ migration) , and reboot the instance, then the bdm will be recreated from what's in the database which will be wrong.