Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Network disconnected when using cloud-init and API #299

Open
hassenius opened this issue Oct 25, 2018 · 3 comments
Open

Network disconnected when using cloud-init and API #299

hassenius opened this issue Oct 25, 2018 · 3 comments

Comments

@hassenius
Copy link

It appears when using cloud-init on linux DeployPkg does not attempt to enable the interfaces
https://gist.github.com/hassenius/4a571955452ad5d1693109a92548f9ee

The problem does not appear when deploying manually from vsphere client, as it seems this will have some default setting to enable NIC at boot. However, several external API driven solutions do not have this as default, or not even configurable.
I've seen this issue mentioned in several different places, including:
ansible
terraform

So, as far as I can see, cloud-init does not have a way to replicate the functionality in: libDeployPkg/linuxDeployment.c/TryEnableNics and this code is never executed in the CloudInitSetup function.

It is also unclear how to ignore cloud init with VMWAREDEPLOYPKG_HEADER_FLAGS_IGNORE_CLOUD_INIT

In our scenario we just want cloud-init for some simple config injection (ssh keys, etc), we do not want/need cloud-init to manage the network.

With the GOSC workflow raising the interfaces, I don't think it makes sense to force a different usage pattern of the API, rather than making GOSC and cloud-init workflow have the same end result (enabling the interfaces).

@stanguturi
Copy link
Contributor

stanguturi commented Oct 27, 2018

https://gist.github.com/hassenius/4a571955452ad5d1693109a92548f9ee

Yes. The linuxDeployPkg will not enable the NICS when the 'deployment' task is delegated to cloudinit. 'VMware customization' module in cloud-init enables the NICS. Please check the following

In our scenario we just want cloud-init for some simple config injection (ssh keys, etc), we do not want/need cloud-init to manage the network.

Can you please elaborate on your use case?

@hassenius
Copy link
Author

Thanks @stanguturi I'll dig into these two. We're not using OVF, so I guess I'll look at why the cloud-init guestcust util was not exercised to enabling the nic in any of our various configuration attempts.

For our use case, we're primarily looking to have a single standardised vm template that can:

  1. Grow the root partition to any size (was hoping to use the cloud-init growpart module for this)
  2. Have no shared credentials, so create users and credentials at creation time (was hoping to use standard cloud-init ways to do this as we do on other platforms)

Since we're already using Terraform for a lot of our automation, we were hoping to create a fairly easy workflow where terraform would create a cdrom with the user data containing the users and keys to create, upload it to a data store and make sure the vm boots with the cdrom mounted.

Since terraform manages the environment it would also clean up the ISO when tearing down the environment.

jfroche added a commit to IMIO/cloud-init-vmware-guestinfo that referenced this issue Jun 14, 2020
New machines created from a template sometimes don't have its network
interfaces connected to the network. This happen for example when
terraform customize the template after cloning.

To fix this issue, we do the same as DataSourceOVF[1] and make sure that
the interfaces defined by vmware-imc connect using vmware-rpctool.

similar issue: vmware/open-vm-tools#299

[1]: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceOVF.py#L261
jfroche added a commit to IMIO/cloud-init-vmware-guestinfo that referenced this issue Jun 15, 2020
New machines created from a template sometimes don't have its network
interfaces connected to the network. This happen for example when
terraform customize the template after cloning.

To fix this issue, we do the same as DataSourceOVF[1] and make sure that
the interfaces defined by vmware-imc connect using vmware-rpctool.

similar issue: vmware/open-vm-tools#299

[1]: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceOVF.py#L261
jfroche added a commit to IMIO/cloud-init-vmware-guestinfo that referenced this issue Sep 16, 2020
New machines created from a template sometimes don't have its network
interfaces connected to the network. This happen for example when
terraform customize the template after cloning.

To fix this issue, we do the same as DataSourceOVF[1] and make sure that
the interfaces defined by vmware-imc connect using vmware-rpctool.

similar issue: vmware/open-vm-tools#299

[1]: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceOVF.py#L261
jfroche added a commit to IMIO/cloud-init-vmware-guestinfo that referenced this issue Sep 23, 2020
New machines created from a template sometimes don't have its network
interfaces connected to the network. This happen for example when
terraform customize the template after cloning.

To fix this issue, we do the same as DataSourceOVF[1] and make sure that
the interfaces defined by vmware-imc connect using vmware-rpctool.

similar issue: vmware/open-vm-tools#299

[1]: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceOVF.py#L261
@bhundven
Copy link

bhundven commented Feb 9, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants