Ask Your Question

Revision history [back]

This is not a Heat specific problem. Generally, you can’t predict which port is mapped to which interface when creating a server with several NICs. From the API documentation:

This is not a Heat specific problem. Generally, you can’t predict which port is mapped to which interface when creating a server with several NICs. From the API documentation:

If multiple networks are defined, the order in which they appear in the guest operating system will not necessarily reflect the order in which they are given in the server boot request.

The solution given in the API description is tags. You tag NICs, and the instance uses them to map interfaces as intended. There is more info in the spec, but the 5 minutes I spent googling for this were not sufficient to find out how hypervisors support this feature. The spec mentions that a “future version of qemu” may use this feature.

This is not a Heat specific problem. Generally, you can’t predict which port is mapped to which interface when creating a server with several NICs. From the API documentation:

If multiple networks are defined, the order in which they appear in the guest operating system will not necessarily reflect the order in which they are given in the server boot request.

The solution given in the API description is tags. You tag NICs, and the instance uses them to map interfaces as intended. There is more info in the spec, but the 5 minutes I spent googling for this were not sufficient to find out how hypervisors support this feature. The spec mentions that a “future version of qemu” may use this feature.it. If your application retrieves NIC metadata and use it to decide how to configure each NIC, I guess you can live without hypervisor support.

This is not a Heat specific problem. Generally, you can’t predict which port is mapped to which interface when creating a server with several NICs. From the API documentation:

If multiple networks are defined, the order in which they appear in the guest operating system will not necessarily reflect the order in which they are given in the server boot request.

The solution given in the API description is tags. You tag NICs, and the instance uses them to map interfaces as intended. There is more info in the spec, but the 5 minutes I spent googling for this were not sufficient to find out how hypervisors support this feature. The spec mentions that a “future version of qemu” may use it. If your application retrieves bases NIC metadata and use it to decide how to configure each NIC, configuration on NIC tags, I guess you can live without hypervisor support.