Implementing integrated DNS, DHCP and IP address management

As a cloud administrator, you have the ability to specify the DNS server for the container-level networks and NAT pools when creating the container, by configuring integrated DDI (DNS, DHCP, and IPAM).

This topic contains the following sections:

Overview of the integration

This DDI integration provides the ability to:

  • Onboard a pod with DNS server details
  • Pass DNS details to BMC Atrium Orchestrator callouts for further DNS registration
  • Create a network container that has the DNS server defined on the container level network

Back to top

To set up DNS details in BMC Cloud Lifecycle Management

The cloud administrator passes the host name, transaction ID, and NIC ID to BMC Network Automation to acquire a static IP address for the VM being provisioned. DNS registration for static IPs is the default behavior and the administrator cannot change it from the BMC Cloud Lifecycle Management GUI. 

Similarly, BMC Cloud Lifecycle Management calls BMC Network Automation to release a static IP address to decommission a VM.

Back to top

To set up DNS details in BMC Network Automation

In BMC Network Automation, you can specify the primary DNS, reverse DNS server, secondary DNS, DNS suffix, DNS search order, and reverse DNS zone in the DNS and NIC Information, Address Pool, and Address Range pages when creating the pod. For details, see  Creating a pod from a pod blueprint in the BMC Network Automation online technical documentation.

Note

If the pod level address pool is not shareable, you cannot edit the DNS information after the pod has been created. However, if the pod level address pool is shareable, you can edit the DNS information.

These settings can then be overridden during container creation in BMC Network Automation by setting the performDnsOperation property in the global.properties file to false. However, the ability to specify the DNS information per address pool is not available using BMC Cloud Lifecycle Management. Therefore, create the network container in BMC Network Automation and then use the Simple Object Access Protocol (SOAP) client to modify the container to assign DNS information (on a per address pool level). Alternatively, you could use the  container utility shipped with BMC Network Automation.

The following figure shows a Network Container where the DNS information has been set.

Back to top

To submit the service offering instance after DNS configuration or server onboard

Once you have set the DNS details, you can provision the service offering instance as you normally would in BMC Cloud Lifecycle Management. This DNS information is used for static IPs only. During the creation of a static NIC, the DNS information obtained from BMC Network Automation is persisted in CLMDB for each static IP. At the same time, the DNS information is automatically configured on the provisioned server.  

Note

For an AIX server, only the primary DNS and DNS suffix are configured on the server; the remaining DNS configurations must be set using the Local Properties - AIX tab in the BMC Server Automation AIX system package.

  • For a management static IP, the local properties are ETH0_PRIMARYDNS, ETH0_SECONDARYDNS, and so on.
  • For non-management static IPs, the properties are ETH1_PRIMARY for the first IP, and ETH1_1_PRIMARY(for example) for successive IPs. Successive IPs use the IP-index in the property name.

In the case of a server onboard, the DNS information obtained from the virtual guest is assumed to be correct, irrespective of what is configured in BMC Network Automation and that is what persisted in BMC Cloud Lifecycle Management.

Back to top

To view DNS details on CLM server details section

You can view the DNS details in BMC Cloud Lifecycle Management by selecting Service Instances > My Services > Servers > IP Addresses, as shown in the figure below.

For static IP addresses, click the DNS details button to view the DNS information.

Back to top

To use the DNS details for registration and de-registration through callouts

During virtual guest pre-callout, the IP and its DDI information is available for DNS registration on the DNS server. In previous versions, the DNS information had to be hardcoded in the callout, irrespective of IP. With this integration, the DNS information can be registered on different DNS servers.

Similar to DNS registration, deregistration is also accomplished using custom code in a callout during the service offering instance decommission.

For information about using callouts, see Callouts and Callout API reference.

Back to top

Was this page helpful? Yes No Submitting... Thank you

Comments