Initializing a Linux virtual machine with the VM Initialization Tool

Q: Configuring the DNS server via cloud-init on CentOS 7.x does not take effect even though cloud-init runs successfully. Why?

A: This issue can occur if the virtual machine template has three DNS servers already configured in the /etc/resolv.conf file and does not allow adding more, which is typical for Linux distros that uses /etc/resolv.conf for DNS configuration. The cause is that cloud-init implements its DNS server configuration by adding the new server to the existing ones in resolv.conf rather than replacing them. According to the resolv.conf(5) manual page, a maximum of three DNS servers is allowed in resolv.conf. Therefore, if the virtual machine template already has three DNS servers configured in the /etc/resolv.conf file, attempting to add a new server via cloud-init will fail. In this case, the /var/log/cloud-init.log will record ignoring nameserver {dns_server}: adding would exceed the maximum of '3' name servers (see resolv.conf(5)).

Q: When using cloud-init to configure DNS for operating systems that use the eni network configuration tool (such as Debian OS), the DNS does not take effect even though cloud-init executes normally. Why?

A: This issue may be due to the fact that the virtual machine generally uses resolvconf.service to configure DNS when configuring network through the eni network configuration tool. Some operating systems may not have this service installed, causing DNS configuration to fail. It is necessary to install the resolvconf.service when creating the template and ensure that the service starts automatically upon startup.

Q: For operating systems that use the Netplan network configuration tool to configure networks, such as Kylin Desktop v10, when using cloud-init to configure static IP network, the static IP, routes, DNS configurations do not take effect even though cloud-init runs successfully. Why?

A: This issue may be due to the fact that the virtual machine's Netplan network configuration tool uses the systemd-networkd service to manage the network, but the systemd-networkd service is not set to start automatically upon startup. Although the cloud-init service has written the expected configuration to the Netplan configuration directory, the network configuration may still fail because the systemd-networkd service is not started. In this case, using the netplan apply command can start the systemd-networkd service and apply the relevant configuration. Once the network configuration is restored, the failure described in this question occurs. You can run the command systemctl enable systemd-networkd when creating the cloud-init template to set the service to start automatically upon startup.

Q: When using cloud-init to configure static IP networks for operating systems that use the Netplan network configuration tool (such as Ubuntu 18.04 system), the static IP configuration does not take effect even though cloud-init executes normally. Why?

A: This issue may be due to the existence of multiple configuration files in the /etc/netplan directory, such as 01-network-manager-all.yaml and 50-cloud-init.yaml, which the system will process in order. Therefore, the multiple configuration files may cause configuration conflicts, thus affecting the effectiveness of network settings.

For example, if the 01-network-manager-all.yaml file sets the DHCP configuration for the virtual NIC ens4, this setting may override or interfere with the configuration for ens4 in the 50-cloud-init.yaml file. Additionally, if the 01-network-manager-all.yaml file contains configurations for non-existent NICs, it may also lead to network configuration failure, resulting in the configurations in the 50-cloud-init.yaml file not taking effect.

To address this issue, it is recommended to back up the 01-network-manager-all.yaml file and remove it from the /etc/netplan directory, then recreate the cloud-init template for creating cloud-init virtual machines.

Q: Configuring static IP address via cloud-init on operating systems that use the eni network configuration tool (such as Debian or Ubuntu 16.04) does not take effect even though cloud-init runs successfully. Why?

A: This issue may be due to incorrect configuration of the /etc/network/interfaces file.

Since cloud-init writes network configuration info to the /etc/network/interfaces.d/50-cloud-init.cfg file, if the /etc/network/interfaces file is not configured correctly, the configurations in the 50-cloud-init.cfg file will be ineffective, leading to the static IP address configuration not taking effect.

Refer to the following requirements to configure the /etc/network/interfaces file.

1. Including source statement

   The /etc/network/interfaces file must include the following statements to ensure that configuration files in the /etc/network/interfaces.d/* directory can be loaded:

   source /etc/network/interfaces.d/*

2. Avoiding conflicts

   
   The /etc/network/interfaces file should not contain the same configurations as the NIC specified in the /etc/network/interfaces.d/50-cloud-init.cfg file to prevent configuration conflicts.

Here's an example of a /etc/network/interfaces file that meets the requirements, where only the loopback interface lo is configured:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

To address this issue, it is recommended to modify the configuration as described above to ensure that the network settings in the 50-cloud-init.cfg file can be correctly loaded and take effect.

Q: On certain operating systems (for example, Kylin Desktop V10 SP1), a root password configured by cloud-init containing the ! character does not actually take effect after cloud-init is successfully executed. Why?

A: In Bash, ! is a special character used for history command expansion. If a password contains !, Bash mistakes it as a reference to a history command, making the password ineffective.

To resolve the conflict, you can permanently disable the histexpand feature in Guest OS of the virtual machine template following these steps:

1. Run the following command to open the /etc/bash.bashrc file.

   vim /etc/bash.bashrc

2. Add set +H at the end of the file.

3. Save and exit the editor.

4. Run the following command to immediately apply the configuration.

   source /etc/bash.bashrc

Note:

You can manually activate this feature again after you create a virtual machine.