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

Passthrough of netplan from template networks config to VM #2217

Open
mhio opened this issue Feb 18, 2024 · 0 comments
Open

Passthrough of netplan from template networks config to VM #2217

mhio opened this issue Feb 18, 2024 · 0 comments

Comments

@mhio
Copy link
Contributor

mhio commented Feb 18, 2024

Description

Configuring custom networking in lima can be slightly painful, usually related to non DHCP networks where start up of the VM will have a 120 second timeout for the VM to boot.

  • limactl create --name=vm
  • wait 2 minutes for DHCP timeout
  • Run provisioning to configure netplan as needed.
  • Set network: {config: disabled} in /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
  • netplan apply
  • limactl stop vm
  • limactl start vm

Then remember that you disabled network config next time you edit lima config and wonder why the VM isn't updating to the same spec.

As cloud init already does pass through of version 2 config from the network datasource to netplan, it would be brilliant if lima could pass through netplan config from lima.yml to /mnt/lima-cidata/network-config

I'm not sure if anything in lima's networks schema that clashes with netplan, but lima does have a slightly different base to it's schema so it might be best if the data is nested? Something like:

networks:
  - vzNAT: true
  - lima: 'bridged'
    netplan:
      addresses:
        - 192.168.17.34/23
      routes:
        - to: 192.168.24/23
          via: 192.168.17.99

Then there are probably some precedence questions, for where other lima config already apply's to the /mnt/lima-cidata/network-config file.

Injection of the bonds, bridges and vlans parent types in netplan would not be supported by the above schema, but in my experience those are used more at the hypervisor level.

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

1 participant