NM-CLOUD-SETUP(8)

📦
version 1.58.0 · 11 versions
, in centos-stream 10

🌸 NAME 🌸

okay bestie, welcome to the nm-cloud-setup(8) manual 💅 — the whole vibe here is Overview of Automatic Network Configuration in Cloud. Periodt.

☁️ OVERVIEW ☁️

so when you’re running a virtual machine in a public cloud environment, it’s literally desirable to automatically configure the network of that VM. in simple setups, the VM only has one network interface and the public cloud supports automatic configuration via DHCP, DHCP6 or IPv6 autoconf. iconic. BUT 😭 the virtual machine might have multiple network interfaces, or multiple IP addresses and IP subnets on one interface which cannot be configured via DHCP. also, the administrator may reconfigure the network while the machine is running. NetworkManager’s nm-cloud-setup is a tool that automatically picks up such configuration in cloud environments and updates the network configuration of the host. no cap.

Multiple cloud providers are supported. see the section called SUPPORTED CLOUD PROVIDERS 🫶

🛠️ USE 🛠️

the goal of nm-cloud-setup is to be configuration-less and work automatically ✨ all you need is to opt-in to the desired cloud providers (see the section called ENVIRONMENT VARIABLES) and run /usr/libexec/nm-cloud-setup.

usually this is done by enabling the nm-cloud-setup.service systemd service and letting it run periodically. for that there is both a nm-cloud-setup.timer systemd timer and a NetworkManager dispatcher script. slay.

🔍 DETAILS 🔍

nm-cloud-setup configures the network by fetching the configuration from the well-known meta data server of the cloud provider. that means it already needs the network configured to the point where it can reach the meta data server. commonly that means a simple connection profile is activated that possibly uses DHCP to get the primary IP address. NetworkManager will create such a profile for ethernet devices automatically if it is not configured otherwise via "no-auto-default" setting in NetworkManager.conf. one possible alternative may be to create such an initial profile with nmcli device connect "$DEVICE" or nmcli connection add type ethernet ....

by setting the user-data org.freedesktop.nm-cloud-setup.skip=yes on the profile, nm-cloud-setup will skip the device. bestie, that’s your little “not today” button 🙈

nm-cloud-setup modifies the run time configuration akin to nmcli device modify. with this approach, the configuration is not persisted and only preserved until the device disconnects. main character energy: temporary but unforgettable 💅

🧚 /usr/libexec/nm-cloud-setup 🧚

the binary /usr/libexec/nm-cloud-setup does most of the work. it supports no command line arguments but can be configured via environment variables. see the section called ENVIRONMENT VARIABLES for the supported environment variables.

by default, all cloud providers are disabled unless you opt-in by enabling one or several providers. if cloud providers are enabled, the program tries to fetch the host’s configuration from a meta data server of the cloud via HTTP. if configuration could be not fetched, no cloud provider are detected and the program quits. if host configuration is obtained, the corresponding cloud provider is successfully detected. then the network of the host will be configured.

it is intended to re-run nm-cloud-setup every time when the configuration (maybe) changes. the tool is idempotent, so it should be OK to also run it more often than necessary. you could run /usr/libexec/nm-cloud-setup directly. however it may be preferable to restart the nm-cloud-setup systemd service instead or use the timer or dispatcher script to run it periodically (see below). idempotent queen behavior 👑

🎀 nm-cloud-setup.service systemd unit 🎀

usually /usr/libexec/nm-cloud-setup is not run directly, but only by systemctl restart nm-cloud-setup.service. this ensures that the tool only runs once at any time. the unit is also used by the nm-cloud-setup systemd timer and allows enabling/disabling the service via systemd.

as you need to set environment variable to configure nm-cloud-setup binary, you can do so via systemd override files. try systemctl edit nm-cloud-setup.service. drop-in era 💜

⏰ nm-cloud-setup.timer systemd timer ⏰

/usr/libexec/nm-cloud-setup is intended to run whenever an update is necessary. for example, during boot when when changing the network configuration of the virtual machine via the cloud provider. (yes bestie, “when when” is in the original vibe 😭)

one way to do this, is by enabling the nm-cloud-setup.timer systemd timer with systemctl enable --now nm-cloud-setup.timer. so clean, so periodic, so iconic ✨

🦋 /usr/lib/NetworkManager/dispatcher.d/90-nm-cloud-setup.sh 🦋

there is also a NetworkManager dispatcher script that will run for example when an interface is activated by NetworkManager. together with the nm-cloud-setup.timer systemd timer this script is to automatically pick up changes to the network.

the dispatcher script will do nothing, unless the systemd service is enabled. to use the dispatcher script you should therefore run systemctl enable nm-cloud-setup.service once. one little enable and the script wakes up 🫶

🌈 ENVIRONMENT VARIABLES 🌈

the following environment variables are used to configure /usr/libexec/nm-cloud-setup. you may want to configure them with a drop-in for the systemd service. for example by calling systemctl edit nm-cloud-setup.service and configuring [Service] Environment=, as described in systemd.exec(5) manual.

  • NM_CLOUD_SETUP_LOG — control the logging verbosity. set it to one of TRACE, DEBUG, INFO, WARN, ERR or OFF. the program will print message on stdout and the default level is WARN. when run as systemd service, the log will be collected by journald and can be seen with journalctl.
  • NM_CLOUD_SETUP_AZURE — boolean, whether Microsoft Azure support is enabled. defaults to no.
  • NM_CLOUD_SETUP_EC2 — boolean, whether Amazon EC2 (AWS) support is enabled. defaults to no.
  • NM_CLOUD_SETUP_GCP — boolean, whether Google GCP support is enabled. defaults to no.
  • NM_CLOUD_SETUP_ALIYUN — boolean, whether Alibaba Cloud (Aliyun) support is enabled. defaults to no.
  • NM_CLOUD_SETUP_OCI — boolean, whether Oracle Cloud (OCI) support is enabled. defaults to no.

🐛 DEBUGGING 🐛

enable debug logging by setting NM_CLOUD_SETUP_LOG environment variable to TRACE.

in the common case where nm-cloud-setup is running as systemd service, this can be done via systemctl edit nm-cloud-setup.service and add Environment=NM_CLOUD_SETUP_LOG=TRACE to the [Service] section. afterwards, the log can be found in syslog via journalctl. you may also want to enable debug logging in NetworkManager as described in the DEBUGGING section in NetworkManager(5) manual. when sharing logs, it’s best to share complete logs and not preemptively filter for NetworkManager or nm-cloud-setup logs. full logs, no crumbs, bestie 🌈

🚀 EXAMPLE SETUP FOR CONFIGURING AND PREDEPLOYING NM-CLOUD-SETUP 🚀

as detailed before, nm-cloud-setup needs to be explicitly enabled. as it runs as a systemd service and timer, that basically means to enable and configure those. this can be done by dropping the correct files and symlinks to disk.

the following example enables nm-cloud-setup for Amazon EC2 cloud:

dnf install -y NetworkManager-cloud-setup

mkdir -p /etc/systemd/system/nm-cloud-setup.service.d
cat > /etc/systemd/system/nm-cloud-setup.service.d/10-enable-ec2.conf << EOF
[Service]
Environment=NM_CLOUD_SETUP_EC2=yes
EOF

# systemctl enable nm-cloud-setup.service
mkdir -p /etc/systemd/system/NetworkManager.service.wants/
ln -s /usr/lib/systemd/system/nm-cloud-setup.service /etc/systemd/system/NetworkManager.service.wants/nm-cloud-setup.service

# systemctl enable nm-cloud-setup.timer
mkdir -p /etc/systemd/system/timers.target.wants/
ln -s /etc/systemd/system/timers.target.wants/nm-cloud-setup.timer /usr/lib/systemd/system/nm-cloud-setup.timer

# systemctl daemon-reload

☁️ SUPPORTED CLOUD PROVIDERS ☁️

🌩️ Amazon EC2 (AWS) 🌩️

for AWS, the tools tries to fetch configuration from http://169.254.169.254/. currently, it only configures IPv4 and does nothing about IPv6. it will do the following.

  • first fetch http://169.254.169.254/latest/meta-data/ to determine whether the expected API is present. this determines whether EC2 environment is detected and whether to proceed to configure the host using EC2 meta data.
  • fetch http://169.254.169.254/2018-09-24/meta-data/network/interfaces/macs/ to get the list of available interface. interfaces are identified by their MAC address.
  • then for each interface fetch http://169.254.169.254/2018-09-24/meta-data/network/interfaces/macs/$MAC/subnet-ipv4-cidr-block and http://169.254.169.254/2018-09-24/meta-data/network/interfaces/macs/$MAC/local-ipv4s. thereby we get a list of local IPv4 addresses and one CIDR subnet block.
  • then nm-cloud-setup iterates over all interfaces for which it could fetch IP configuration.
    • if no ethernet device for the respective MAC address is found, it is skipped.
    • also, if the device is currently not activated in NetworkManager or if the currently activated profile has a user-data org.freedesktop.nm-cloud-setup.skip=yes, it is skipped.
    • if only one interface and one address is configured, then the tool does nothing and leaves the automatic configuration that was obtained via DHCP.
    • otherwise, the tool will change the runtime configuration of the device.
      • add static IPv4 addresses for all the configured addresses from local-ipv4s with prefix length according to subnet-ipv4-cidr-block. for example, we might have here 2 IP addresses like "172.16.5.3/24,172.16.5.4/24".
      • choose a route table 30400 + the index of the interface and add a default route 0.0.0.0/0. the gateway is the first IP address in the CIDR subnet block. for example, we might get a route "0.0.0.0/0 172.16.5.1 10 table=30400". also choose a route table 30200 + the interface index. this contains a direct routes to the subnets of this interface.
      • finally, add a policy routing rule for each address. for example priority 30200 from 172.16.5.3/32 table 30200, priority 30200 from 172.16.5.4/32 table 30200 and priority 30400 from 172.16.5.3/32 table 30400, priority 30400 from 172.16.5.4/32 table 30400. the 30200+ rules select the table to reach the subnet directly, while the 30400+ rules use the default route. also add a rule "priority 30350 table main suppress_prefixlength 0". this has a priority between the two previous rules and causes a lookup of routes in the main table while ignoring the default route. the purpose of this is so that other specific routes in the main table are honored over the default route in table 30400+.

With the example above, that's roughly the same as running this for interface eth0:

nmcli device modify "eth0" ipv4.addresses "172.16.5.3/24,172.16.5.4/24" ipv4.routes "172.16.5.0/24 0.0.0.0 10 table=30200, 0.0.0.0/0 172.16.5.1 10 table=30400" ipv4.routing-rules "priority 30200 from 172.16.5.3/32 table 30200, priority 30200 from 172.16.5.4/32 table 30200, priority 20350 table main suppress_prefixlength 0, priority 30400 from 172.16.5.3/32 table 30400, priority 30400 from 172.16.5.4/32 table 30400"

Bestie, heads up: this replaces the previous addresses, routes and rules with the new info. And like… it only changes the run time configuration of the device — the connection profile on disk is not affected. 💅

Google Cloud Platform (GCP) ☁️

For GCP, the meta data is fetched from URIs starting with http://metadata.google.internal/computeMetadata/v1/ with a HTTP header "Metadata-Flavor: Google". Currently, the tool only configures IPv4 and does nothing about IPv6. It will do the following:

For each device, we lookup the currently applied connection in NetworkManager. That implies, that the device is currently activated in NetworkManager. If no such device was in NetworkManager, or if the profile has user-data org.freedesktop.nm-cloud-setup.skip=yes, we skip the device. Now for each found IP address we add a static route "$FIPS_ADDR/32 0.0.0.0 100 type=local" and reapply the change.

The effect is not unlike calling nmcli device modify "$DEVICE" ipv4.routes "$FIPS_ADDR/32 0.0.0.0 100 type=local [,...]" for all relevant devices and all found addresses. 🫶

Microsoft Azure 💠

For Azure, the meta data is fetched from URIs starting with http://169.254.169.254/metadata/instance with a URL parameter "?format=text&api-version=2017-04-02" and a HTTP header "Metadata:true". Currently, the tool only configures IPv4 and does nothing about IPv6. It will do the following:

Then the tool configures the system like doing for AWS environment. That is, using source based policy routing with the tables/rules 30200/30400. ✨

Alibaba Cloud (Aliyun) 🧧

For Aliyun, the tools tries to fetch configuration from http://100.100.100.200/. Currently, it only configures IPv4 and does nothing about IPv6. It will do the following:

Then the tool configures the system like doing for AWS environment. That is, using source based policy routing with the tables/rules 30200/30400. One difference to AWS is that the gateway is also fetched via metadata instead of using the first IP address in the subnet. 👑

Oracle Cloud (OCI) 🧡

For OCI, the tools tries to fetch configuration from http://169.254.169.254/. Currently, it only configures IPv4 and does nothing about IPv6. It will do the following:

  • First fetch http://169.254.169.254/opc/v2/instance to determine whether the expected API is present. This determines whether OCI environment is detected and whether to proceed to configure the host using OCI meta data.
  • Fetch http://169.254.169.254/opc/v2/vnics to get the configuration for all the VNICs, getting their MAC address, private IP address, gateway and subnet block.
  • Then nm-cloud-setup iterates over all interfaces for which it could fetch a configuration. If no ethernet device for the respective MAC address is found, it is skipped. Also, if the device is currently not activated in NetworkManager or if the currently activated profile has a user-data org.freedesktop.nm-cloud-setup.skip=yes, it is skipped. Also, there is only one interface and one IP address, the tool does nothing.

Then the tool configures the system like doing for AWS environment. That is, using source based policy routing with the tables/rules 30200/30400. 🌈

🌸 SEE ALSO 🌸

Okay bestie, that's the whole page — you ate that. 💖 This masterpiece is from NetworkManager 1.58.0, dated NM-CLOUD-SETUP(8) — go forth and let the cloud configure itself, no cap. 🦋✨🎀

📦 where this page comes from