With vzNAT - how can I force the lima0 ip address [ the one available from host ] ?

[cgimenez]

Hi all and cudos for the work done on Lima !

limactl create --name vm1 ./myconfig.yaml # see below

the lima0 interface vm IP address is : 192.168.64.X

• I can ping / connect from host to guest w/o problem
• But how can I force this address when the vm is created ?
• when creating / destroying virtual machines X is always incremented and never reused (and I've not found where this counter is stored)

So, I would like to create a VM reusing the same IP used by the last destroyed vm

Disclaimer : I discovered lima this morning, so total noob ;-)

Note : I'm using the macports version of Lima

# This template requires Lima v0.7.0 or later
# https://github.com/lima-vm/lima/blob/master/examples/default.yaml
# limactl create --tty=false --name "vm3" ./config.yaml
images:
  # Try to use release-yyyyMMdd image if available. Note that release-yyyyMMdd will be removed after several months.
  - location: "https://cloud.debian.org/images/cloud/bookworm/20240717-1811/debian-12-genericcloud-amd64-20240717-1811.qcow2"
    arch: "x86_64"
    digest: "sha512:0f0075d53749dba4c9825e606899360626bb20ac6bab3dbdeff40041b051d203eb1a56e68d377c9fac0187faa0aea77fd543ef4a883fff2304eac252cce01b44"
  - location: "https://cloud.debian.org/images/cloud/bookworm/20240717-1811/debian-12-genericcloud-arm64-20240717-1811.qcow2"
    arch: "aarch64"
    digest: "sha512:a68fe32c459d6d33cd8f6798fe7e2278d32add2b9506f4a6c434328a0a9cd176e532a93d0184173720023db5edfd93061082fadcb91bb3e95988564c63f139a6"
  # Fallback to the latest release image.
  # Hint: run `limactl prune` to invalidate the cache
  - location: "https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-amd64.qcow2"
    arch: "x86_64"
  - location: "https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-arm64.qcow2"
    arch: "aarch64"
vmType: "vz"
cpus: 2
memory: 8Gib
disk: 60Gib
networks:
  - vzNAT: true

hostResolver:
  enabled: true

mounts:
  - location: "~/lima_shared"
    writable: false
mountType: "virtiofs"

[jandubois]

This happens when the vmType is set to vz. For qemu we generate a MAC address based on the Lima instance name, and network index in the lima.yaml file. So the MAC address will remain the same when you delete and recreate an instance with the same name and template.

For VZ we seem to generate a new UUID via vz.NewGenericMachineIdentifier() every time we create an instance (stored in the vz-identifier file in the Lima instance directory. I assume that VZ will generate a MAC address based on this UUID. So as long as you stop/start an existing instance, the MAC address will remain the same, and DHCP will return the same IP address. But when you delete the instance, the UUID will be randomly generated and you end up with a different MAC address, and DHCP will not return the old IP address because it still has an unexpired lease from the old MAC address.

I don't know if we have the ability to generate the UUID ourselves instead of letting the VZ library pick one for us. Can you file a GitHub issue for this?

[nirs]

We can create new uuid from instance name. Here is a python example I'm using for vfkit:

md = hashlib.sha256(name.encode()).digest()
instance_uuid = str(uuid.UUID(bytes=md[:16], version=4))

Of course we using only 16 random bytes form 32 bytes sha256 digest makes this more likely to clash with another vm, but it is much better than creating 6 bytes random mac address.

Instance name should be "lima-{name}" to avoid clashing with minikube or vfkit vms using the same name.

[nirs]

Another option is using go-vmnet - used by minikube:
https://pkg.go.dev/github.com/zchee/go-vmnet?utm_source=godoc

I don't think this is a robust way, it is probably abusing the API and likely to break in future update.

However it work like this:

1. Create vmnet interface with vmnet_operation_mode_key and vmnet_interface_id_key
   • This does not require root - probably bug in vmnet.
2. fetch the vmnet_mac_address_key from the params
3. stop the interface
4. Start the vm with the same uuid, you will get the same mac address (cached in /var/db/dhcpd_leases)

This will break if someone clears /var/db/dhcpd_leases between step 3 and 4.