The file copy is from the live-migration source host to the destination host and the command is run on the *destination* host instead of the source host. My gut feeling is that live_migration_inbound_addr is only applicable when running live-migration related operations on the *source* host after the destination host passes live_migration_inbound_addr of the destination host itself as the *inbound* address using the pre_live_migration phase.
Using instance.host instead of using an explicit address probably doesn't reflect the operator's intention of setting live_migration_inbound_addr so it's an upstream issue ultimately IMHO. However, using config_drive_format=iso9660 is known tricky in the upstream as the code comment suggests: https://bugs.launchpad.net/nova/+bug/1246201
So the quickest workaround would be using config_drive_format=vfat to avoid running that part of the code.
This part of the code is a bit tricky: /github. com/openstack/ nova/blob/ stable/ ussuri/ nova/virt/ libvirt/ driver. py#L9616- L9628
https:/
The file copy is from the live-migration source host to the destination host and the command is run on the *destination* host instead of the source host. My gut feeling is that live_migration_ inbound_ addr is only applicable when running live-migration related operations on the *source* host after the destination host passes live_migration_ inbound_ addr of the destination host itself as the *inbound* address using the pre_live_migration phase.
Using instance.host instead of using an explicit address probably doesn't reflect the operator's intention of setting live_migration_ inbound_ addr so it's an upstream issue ultimately IMHO. However, using config_ drive_format= iso9660 is known tricky in the upstream as the code comment suggests: /bugs.launchpad .net/nova/ +bug/1246201
https:/
So the quickest workaround would be using config_ drive_format= vfat to avoid running that part of the code.
$ juju config nova-compute-* config- flags=' config_ drive_format= vfat'