Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
VMware OVA 00-.network file breaks network connectivity #1802
Container Linux Version
VMware OVA using vApp options to utilize a base64 cloud-config.
Docker Containers have consistently full networking and are able to ping to the Docker virtual gateway and beyond. For the default cloud-config for VMware OVA NOT to create a base highest priority network config file.
Intermittent network failures resulting in loss of network connectivity to outside of the container. During the cloud-config bootstrap the following can be seen within the cloud init logs:
During a failure event running the command
As it is prefixed with
Removing the 00-.network file has so far resolved the issues surrounding this bug.
It looks like the issue is that the OVA template is populating both
I believe you can work around the issue by setting
Apologies for reviving an old ticket but I ran into this last week and I'm curious whether there's more to fix here or whether (the more likely outcome) we were just being daft.
For a certain set of VMs I had a MOP for creating them in vSphere which involved setting DHCP to no during creation, booting the machine (which had a custom network unit that matched on Name=ens192 and had DHCP=yes). Turning the machine off, setting vApp options DHCP to yes and then booting the machine again.
I think that MOP was created before this fix as a workaround for the issue (presumably because we didn't get to the bottom of it) although that's not really the key point here.
However, following the MOP with the latest ova will reproduce this issue. Essentially, if I take a coreos machine in a working state, turn it off, set dhcp to yes in vApp options in vsphere and turn it back on again then the 00-.network file is created with a blank match statement. Is that just a fundamentally broken this to do and anyone who knew what they were doing wouldn't dream of it or is there further work required on this ticket to avoid getting into the broken state?
We definitely don't need to fiddle with vApp options any more - it's not even clear to me why we ever were.
I just wanted to make sure there wasn't some low hanging fruit here in documentation fixes/config changes that would make it clearer that we shouldn't have done this (or ideally prevent it). No worries at all if not, you have to fall back to the flash vsphere app to even edit the vapp options after boot so I can't imagine many people running into this!