This message was deleted.

At the moment we don't parse network data, which settings are you trying to carry over? The DHCP identifier?

Hey @agreeable-oil-87482 Indeed, in netplan language:

critical: true
      dhcp-identifier: mac

This is to use old fashioned mac addresses as dhcp identifiers and the critical field prevents the lease from being released upon reboot. I know this can be fed to the image using metadata or vendordata. I haven't been able to use guestinfo (I tried setting the appropriate vm configuration options) because cloud-id detects the source as nocloud instead of vmware. I'm currently thinking of baking the file into the ova. What is the

cloudinit

field for? The options passed to

cloudConfig

apply fine, but unfortunately network options get ignored by design.

A couple of things I would try: 1. Configure your VM template to have this netplan config file set. Then in

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

add the line

network: {config: disabled}

so it won't alter or create a new netplan file 2. Use the user-data part of cloud-init to run a script which amends the netplan config file (or create a new one) and restart netplan.

Do you think I could just run a userdata script to add the

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

file and then remove the cloudinit generated netplan file, apply my own one and reboot? it would have to be early in the process to run before rke components are installed, in case the ip changes again

Could do... Better to do it in the template though

Sure, I actually had to modify the OVF anyway since it comes with VM hardware compatibility level of 10 and 13 is needed for CSI volume attachments... That part was easy since it's just an XML file; however, I did wonder if the VM version can be upgraded during clusterapi/Rancher's VM provisioning process

Currently, no. It's not something we'd want to mandate as it can have implications. You can also turn the template into a VM -> upgrade compatibility -> convert back to template

I was just checking, an option to optionally convert the VM version at provisioning time would be nice but it can be worked around. Considering version 10 is EOL for 2 years now, I'd actually expect the OVF to get the version bumped up sometime. Even vsphere 6.5 which is vm version 13 is EOL