Network is in a disconnected state when using cloudbase-init and Static IP network assignment

[vmwarelab]

would appreciate any help from the cloudbase-init team on this .

Provisioning a VM from a template prepped with cloudbase-init and the OVF service on vSphere via an automation tool that maps userdata using CD-ROM mapped iso works fine if we use DHCP network assignment since in this use case there is no VM customization event which is again is not needed since the template is syspreped.

Problem is when we try to use a static IP the automation tool generate a dynamic customization Specification which forces VM Customization on the provisioned VM . in this use case the customization event fails with an error on the VM in vCenter:

"The customization component failed to set the required parameters inside the guest operating system"

looking in the c:/windows/temp/vmware-imc/guestcust.log I really cloudn't tell what is that required parameters its talking about.

Log Files attached guestcust.log cloudbase-init.log

because of this customization error the network adapter stays in a disconnected state which is problematic even though the IP is configured correctly within the GOS but whats strange cloudbase-init is clearing the gateway, so its not set.

Can cloudbase-init handle something like vSphere Customization ?

[vmwarelab]

looks like i need to use this plug-in cloudbaseinit.plugins.common.networkconfig.NetworkConfigPlugin

so i added it to the cloudbase-init.conf file but Still got the same customization error

so i m not sure what else to do at this point

What is the process of updating an existing template that was already prepped with cloudbase-init .. i had to uninstall and then reinstall cloudbase-init and reconfigure all the conf files and apply sysprep . is that correct or is there a better way ?

[ader1990]

@vmwarelab I do not have much experience on how the VM Customization works, maybe the original patch owner (@jdillet) that added support for OVF can help on this matter.

What I can confirm is that cloudbase-init does not support static network configuration for OVF metadata service. See https://cloudbase-init.readthedocs.io/en/latest/services.html#open-virtualization-format-ovf

To move further, can you provide the config drive contents? The default OVF drive label is OVF ENV. If cloudbase-init can get the static network information from the metadata file, then support can be added for this feature.

Thank you, Adrian Vladu

[vmwarelab]

@jdillet like me works for VMware as well and he is already aware of this since i copied him internally .. i didn't know he was the original patch owner.

here is the ovf-env.xml that is mapped via the CD-ROM i have renamed it to .txt ovf-env.txt

is that what your asking for ? the userdata seems to be encrypted !! so i can't really see my cloud config code that i passed from t he automation tool

[vmwarelab]

I can't see within the ovf section based on the link you posted anything that says static networking isn't supported unless i m blind to see it :)

Majority of customers that i deal with don't use DHCP within their production networks .. which makes cloudbase-init really unusable at this point if it does't support static networking. Therefore this would be a very important feature to support.

also by the way the cloud config code i am testing simply to create a file with some sample text content did execute since the automation does pass the user data but the issue is the adapter again in disconnected state since the customization is failing after install cloudbase-init .. yes customization works fine if i dont prep the template with cloudbase-init

[ader1990]

I can't see within the ovf section based on the link you posted anything that says static networking isn't supported unless i m blind to see it :)

Majority of customers that i deal with don't use DHCP within their production networks .. which makes cloudbase-init really unusable at this point if it does't support static networking. Therefore this would be a very important feature to support.

also by the way the cloud config code i am testing simply to create a file with some sample text content did execute since the automation does pass the user data but the issue is the adapter again in disconnected state since the customization is failing after install cloudbase-init .. yes customization works fine if i dont prep the template with cloudbase-init

The OVF metadata service has currently only these capabilities:

• instance id (hardcoded to iid-ovf if not present)
• hostname
• public keys
• admin user name
• admin user password
• user data

From cloud-init, these patches were required to have the static networking configured:

https://github.com/canonical/cloud-init/commit/8844ffb5988bcfbb8cfbe57d9139c3dcb8b429cc#diff-bf224ee6b5520e1165bae72949491277

https://github.com/canonical/cloud-init/commit/39f668e5db8d09c46eee3a5df73a69f8d85ba489#diff-bf224ee6b5520e1165bae72949491277

In the best case scenario, the patches have to be made compatible with the Windows networking implementation (if not rewritten or heavily refactored).

Do you happen to have some details on how the VM configuration works on Windows, so that we can have an idea of what needs to be done?

The main thing would be to find how Cloudbase-Init should run at the proper time and consume the network information in order to set it correctly.

[lapawa]

Any progress on this issue?

I had the same troubles with regular cloud-init on a CentOS 8.2. The solution was to use a combination of vCenter Customization and cloud-init. The first run handles the network configuration with DataSourceOVF [seed=vmware-tools]. This datasource contains the network configuration and is only available on the first boot of the cloned template after a Guest Customization Task in vCenter. This phase replaces a DHCP configuration with static network configuration.

A second run of cloud-init picked the DataSourceOVF [seed=iso] with the above mentioned ovf-env.xml file from the ISO image. This includes some user-data but not the network configuration. The ISO image will stay for the whole lifetime of the VM in the drive.

The question is: Can we disable network and hostname configuration in cloudbase-init as VMware Tools did it already with the guest customization mechanism before?

Or can cloudbase-init use both datasources? vmware-tools AND iso? With a joined dataset of network config and user-data.

When vCenter starts a Customization it configures its own sysprep run and overwrites the cloudbase-init unattended run. This results in a missing cloudbase-init-unattended log file.

It seems here are fighting two different customization processes! vmware-tools and cloudbase-init.

Tim

[ader1990]

Hello @lapawa ,

Sorry for the late response. Currently, I do not have access to such an environment but it is clear that vmware-tools and cloudbase-init step on each other toes. What I can suggest is to tweak the cloudbase-init installation so that it sets the cloudbase-init service to automated start or even better, delayed start and disable / remove SetSetupComplete.cmd code. It is same behaviour used here: https://github.com/cloudbase/windows-openstack-imaging-tools/blob/master/UnattendResources/Logon.ps1#L611

Also, you can customize cloudbase-init by writing the code necessary for the use both datasources: vmware-tools AND iso. I can help with the review and testing of that code.

Thank you, Adrian Vladu

[ElVirtualJefe]

I am having this issue, currently... Has there been any update on if the OVF Service will allow Static Networking?

I'm using 1.1.2 stable.

[jddemcher]

I am also having the same issue, attempting to use cloudbase-init for guest actions. We are using the Infoblox IPAM plugin with static IP assignment, in our case the guest OS network settings are applied correctly and the cloudbase-init commands seem to be working fine for setting hostname/admin credentials, but the VM is left with the network adapter in a disconnected state.

[vmwarelab]

check if the vCenter VM customization completed successfully . usually once the customization task is complete and the vm reboots it should connect the adapter

[cmgrayb]

With VMware now recommending using CloudBase-Init for customization of Windows guest OSes, static networking is an absolute threadbare minimum it needs to support to properly replace Guest Customization and the vRA Agent. more info Has there been any movement toward supporting static network IP assignments as exists for Linux?

[ElVirtualJefe]

I just wanted to provide an update on this as to what I have figured out. I found a way to work around this with a poorly documented option in vRA. Here is the documentation.

The option is 'customizeGuestOs', which you can set to false, to keep vRA from generating and applying a dynamic customization specification.

I wrote up a blog post on it here. Thanks to @vmwarelab for your blog posts, which pointed me in the right direction to get this figured out on my end.

For the record, this is not an issue with cloudbase-init so to speak, it is basically an unavoidable race condition, where the dynamic customization spec and cloudbase-init fight to complete their customizations at the same time. The only real solution I have found, is to use one without the other.

[cmgrayb]

Following up, this is how we made VMware's Guest OS Customization and cloudbase-init get along to avoid the original NIC disconnected issue, while still preserving as much of the intended functionality of both as possible. Note that if you are not using vRealize Automation, vCloud Director, or another system mimicking them, you should not need this and should likely be looking into a more appropriate transport such as ConfigDrive. Feel free to adjust locations and file names as you see fit, but ensure you are replacing them in all locations if you do.

1. In your template, create C:\opt\run_cloud-init_prep.ps1, containing the following:

   Set-Service -Name 'cloudbase-init' -StartupType Automatic
   Start-Service -Name 'cloudbase-init'

2. In a UAC-elevated (run as administrator) PowerShell 5.1 window, download cloudbase-init and install it. Adjust your administrator user account and the source URL as necessary. Note that we are -not- sysprepping the machine, as Guest Customization will handle that for you.

   
   $cbiinstaller = "https://github.com/cloudbase/cloudbase-init/releases/download/1.1.2/CloudbaseInitSetup_1_1_2_x64.msi"
   $cbiinstallfile = ("C:\opt\"+(($cbiinstaller).Split('/')[-1]))
   Invoke-WebRequest -Uri $cbiinstaller -UseBasicParsing -OutFile $cbiinstallfile

$cloudinitarguments = @( "/i", $cbiinstallfile, "SYSPREP=0", "SYSPREPSHUTDOWN=0", "RUN_SERVICE_AS_LOCAL_SYSTEM=1", "USERNAME=Administrator", "/qb" ) Start-Process -FilePath 'msiexec.exe' -ArgumentList $cloudinitarguments -Wait Set-Service -Name 'cloudbase-init' -StartupType Disabled

3. Modify the two configuration files as documented by VMware using your preferred method:  [(external link)](https://blogs.vmware.com/management/2019/11/cloudbase-init-windows-initialization.html)

4. Back in your elevated PowerShell window, create a scheduled task with highest privileges but no schedule to allow you to modify and start the cloudbase-init service after the machine finishes sysprepping:

$scheduledtaskaction = New-ScheduledTaskAction -Execute 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe' -Argument 'C:\opt\run_cloud-init_prep.ps1' $principal = New-ScheduledTaskPrincipal -RunLevel Highest -UserId 'NT AUTHORITY\SYSTEM' $st = New-ScheduledTask -Action $scheduledtaskaction -Description 'Starts cloudbase-init after VMware guest customization' -Principal $principal Register-ScheduledTask -TaskName 'cloudbase-init' -InputObject $st

5. Take care of any other rollback steps you would normally handle, such as removing static IPs, old profiles, etc., shut the machine down and convert it to a template.

6. In your VM Customization Specification, add the following to RunOnce:
`C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -Command "Start-ScheduledTask -TaskName 'cloudbase-init'"`

Cloudbase-init will now only run after VMware Guest Customization has completed all of its tasks, which prevents the race condition and also allows the image to be updated without running a cleanup phase for cloudbase-init.  You should now be able to deploy as normal, adding your cloudConfig block for user-data as documented, enjoying all of the benefits of vSphere customization with all of the post-provisioning of cloudbase-init.

For what it is worth, correcting my prior statement, we also had to do something similar in Linux with cloud-init, but that is another post for another place.