You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When Guest Customization is used together with cloud-init to bootstrap a Linux machine, a customized network configuration either fails to take effect on the first boot, or is removed on subsequent boots.
CAPVCD customizes the network configuration, namely it configures a Static IP. VCD makes this information available to the VM using Guest Customization on the first boot.
When the machine first boots, cloud-init runs. To customize the network configuration, it must delegate to the VMware Guest Tools, because cloud-init network configuration is found in metadata, and CAPVCD does not define any cloud-init metadata. VMware Guest Tools correctly configures the network.
However, if the machine ever reboots, the Guest Customizaton data is not available (it is, by design, available only on first boot, or whenever the information changes). As a result, cloud-init believes it is running on a first boot, and tries to configure the network again, delegates to VMware Guest Tools, which now does not have the information it needs, so it fails to configure the network[1].
When VMware Guest Tools fails to configure the network, cloud-init uses its "fallback" network configuration, which is DHCP on both RHEL and Ubuntu. On RHEL, it overwrites the correct network configuration; the machine no longer has network connectivity. On Ubuntu, cloud- writes a network configuration that, by total coincidence, has a lower priority than the one written on first boot; the machine continues to have network connectivity.
CAPVCD should define cloud-init metadata with the network configuration, namely:
Create a VM, with Guest Customization disabled, in a powered-off state
After VCD creates the VM, read the Static IP information from the VM properties
Generate the cloud-init metadata from this information
Encode the metadata using base64 and create two VM properties:
guestinfo.metadata:
guestinfo.metadata.encoding: base64
Power on the VM
On first boot, cloud-init will use the metadata to configure the network. On subsequent boots, it will do the same.
This proposal is similar to what CAPVCD already does, namely, it creates the VM in a powered-off state, writes cloud-init userdata, and then powers on the VM. However, I need help to identify the VCD API to use in Step 2 to retrieve the VM properties.
Describe alternatives you've considered
I've tried the workarounds described in the RHEL and Ubuntu bug reports. They require preventing cloud-init from configuring the network after first boot. The workarounds are complex, and stateful, and frankly, hard to validate, because of the interaction between cloud-init and VMware Guest Tools.
dlipovetsky
changed the title
Do not use Guest Customization to configure machine networking
Use cloud-init metadata to configure the VM network
Aug 17, 2023
The long-standing issue you mentioned in [1] has been resolved in cloud-init 24.2 release, the commit is canonical/cloud-init@9929a00. After reboot, cloud-init won't use fallback DHCP network configuration, the network configuration set according to Guest Customization data will be preserved.
Is your feature request related to a problem? Please describe.
When Guest Customization is used together with cloud-init to bootstrap a Linux machine, a customized network configuration either fails to take effect on the first boot, or is removed on subsequent boots.
CAPVCD customizes the network configuration, namely it configures a Static IP. VCD makes this information available to the VM using Guest Customization on the first boot.
When the machine first boots, cloud-init runs. To customize the network configuration, it must delegate to the VMware Guest Tools, because cloud-init network configuration is found in metadata, and CAPVCD does not define any cloud-init metadata. VMware Guest Tools correctly configures the network.
However, if the machine ever reboots, the Guest Customizaton data is not available (it is, by design, available only on first boot, or whenever the information changes). As a result, cloud-init believes it is running on a first boot, and tries to configure the network again, delegates to VMware Guest Tools, which now does not have the information it needs, so it fails to configure the network[1].
When VMware Guest Tools fails to configure the network, cloud-init uses its "fallback" network configuration, which is DHCP on both RHEL and Ubuntu. On RHEL, it overwrites the correct network configuration; the machine no longer has network connectivity. On Ubuntu, cloud- writes a network configuration that, by total coincidence, has a lower priority than the one written on first boot; the machine continues to have network connectivity.
[1] This is a long-standing issue, reported in 2019 for both RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=1750862), and Ubuntu (https://bugs.launchpad.net/cloud-init/+bug/1835205).
Describe the solution you'd like
CAPVCD should define cloud-init metadata with the network configuration, namely:
On first boot, cloud-init will use the metadata to configure the network. On subsequent boots, it will do the same.
This proposal is similar to what CAPVCD already does, namely, it creates the VM in a powered-off state, writes cloud-init userdata, and then powers on the VM. However, I need help to identify the VCD API to use in Step 2 to retrieve the VM properties.
Describe alternatives you've considered
I've tried the workarounds described in the RHEL and Ubuntu bug reports. They require preventing cloud-init from configuring the network after first boot. The workarounds are complex, and stateful, and frankly, hard to validate, because of the interaction between cloud-init and VMware Guest Tools.
Additional context
This issue is the result of a thread in CAPVCD slack.
The text was updated successfully, but these errors were encountered: