Public bug reported: Description =========== The binding profile of a port is lost after live migration when binding-extended API is enabled.
Details =========== It can be fixed by correctly populating the profile field in the check_can_live_migrate_destination method of nova-compute. This ensures the existing binding profile of the port is retained during port binding in nova-conductor. Please see the Analysis below for more details: This bug was introduced together with Live migration indirect port support. https://review.opendev.org/c/openstack/nova/+/620115 Steps to reproduce =========== 1. Create VM `openstack server create --network $network_id --image $image --flavor $flavor test-vm` 2. Find the associated port with that VM and set the binding profile `openstack port set $port_id --binding-profile aaa=bbb --binding-profile ccc=ddd` You can see binding_profile is successfully set. +-------------------------+-----------------------------------------------------------------------------+ | Field | Value | +-------------------------+-----------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | $HV_id | | binding_profile | aaa='bbb', ccc='ddd' | 3. Perform live-migration `openstack server migrate --live-migration $server_id --wait` 4. Check the port again `openstack port show $port_id` You can see the binding_profile has been overwritten to `os_vif_delegation='True' +-------------------------+-----------------------------------------------------------------------------+ | Field | Value | +-------------------------+-----------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | $HV_id | | binding_profile | os_vif_delegation='True' | | binding_vif_details | bound_drivers.0='gamma', connectivity='l3', port_filter='True' Analysis =========== This patch explains the flow of the port migration during live migration. https://review.opendev.org/c/openstack/nova/+/620115 1. nova-condutor nova-conductor sends a RPC call of check_can_live_migrate_destination to the nova-compute on the destination node to get the migration data before the live migration. 2. nova-compute Once the destination node, nova-compute receives the RPC call and constructs the VIFMigrateData with fields partially populated by create_skeleton_migrate_vifs(). The purpose of partially populating the fields is to allow 'nova-conductor' to update them when binding the ports on the destination host later on. check_can_live_migrate_destination() create_skeleton_migrate_vifs() Note since binding-extended API is enabled, , all VIFMigrateData instances created here only have port_id and source_vif populated. The profile field is NONE and the old information of the VIFs is not carried on. Later, supports_os_vif_delegation is called for all the migration VIFs. Therefore, {"os_vif_delegation": true} is the only data set in the profile filed. vif.supports_os_vif_delegation = True 3. nova-conductor Then nova-conductor tries to bind ports on the destination host with profile from the migration_data given in the previous step. In particular, port_profiles[port_id] (created from the migration data that only has "os_vif_delegation": true}) is used, instead of the current port information from the neutron API (vif['profile'] ). As a result, a port binding profile is set to the {"os_vif_delegation": true} after live-migration Environment =========== Caracal release (2024.1) References =========== https://docs.openstack.org/neutron/latest/contributor/internals/live_migration.html https://review.opendev.org/c/openstack/nova/+/620115 ** Affects: nova Importance: Undecided Assignee: Nisha Brahmankar (nishagb) Status: New ** Changed in: nova Assignee: (unassigned) => Nisha Brahmankar (nishagb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2089566 Title: Retain port binding profile after live migration Status in OpenStack Compute (nova): New Bug description: Description =========== The binding profile of a port is lost after live migration when binding-extended API is enabled. Details =========== It can be fixed by correctly populating the profile field in the check_can_live_migrate_destination method of nova-compute. This ensures the existing binding profile of the port is retained during port binding in nova-conductor. Please see the Analysis below for more details: This bug was introduced together with Live migration indirect port support. https://review.opendev.org/c/openstack/nova/+/620115 Steps to reproduce =========== 1. Create VM `openstack server create --network $network_id --image $image --flavor $flavor test-vm` 2. Find the associated port with that VM and set the binding profile `openstack port set $port_id --binding-profile aaa=bbb --binding-profile ccc=ddd` You can see binding_profile is successfully set. +-------------------------+-----------------------------------------------------------------------------+ | Field | Value | +-------------------------+-----------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | $HV_id | | binding_profile | aaa='bbb', ccc='ddd' | 3. Perform live-migration `openstack server migrate --live-migration $server_id --wait` 4. Check the port again `openstack port show $port_id` You can see the binding_profile has been overwritten to `os_vif_delegation='True' +-------------------------+-----------------------------------------------------------------------------+ | Field | Value | +-------------------------+-----------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | $HV_id | | binding_profile | os_vif_delegation='True' | | binding_vif_details | bound_drivers.0='gamma', connectivity='l3', port_filter='True' Analysis =========== This patch explains the flow of the port migration during live migration. https://review.opendev.org/c/openstack/nova/+/620115 1. nova-condutor nova-conductor sends a RPC call of check_can_live_migrate_destination to the nova-compute on the destination node to get the migration data before the live migration. 2. nova-compute Once the destination node, nova-compute receives the RPC call and constructs the VIFMigrateData with fields partially populated by create_skeleton_migrate_vifs(). The purpose of partially populating the fields is to allow 'nova-conductor' to update them when binding the ports on the destination host later on. check_can_live_migrate_destination() create_skeleton_migrate_vifs() Note since binding-extended API is enabled, , all VIFMigrateData instances created here only have port_id and source_vif populated. The profile field is NONE and the old information of the VIFs is not carried on. Later, supports_os_vif_delegation is called for all the migration VIFs. Therefore, {"os_vif_delegation": true} is the only data set in the profile filed. vif.supports_os_vif_delegation = True 3. nova-conductor Then nova-conductor tries to bind ports on the destination host with profile from the migration_data given in the previous step. In particular, port_profiles[port_id] (created from the migration data that only has "os_vif_delegation": true}) is used, instead of the current port information from the neutron API (vif['profile'] ). As a result, a port binding profile is set to the {"os_vif_delegation": true} after live-migration Environment =========== Caracal release (2024.1) References =========== https://docs.openstack.org/neutron/latest/contributor/internals/live_migration.html https://review.opendev.org/c/openstack/nova/+/620115 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2089566/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
