I am encountering a strange issue where I have set ipv4.address on current profile for a virtual machine but it seems its still pulling some address dynamically.
Thanks @tomp I already rebooted it and can still see this on lxd network list-leases. One thing to note is that the ipv4.address where already specified in the profile prior to doing init and starting the VM. It seems to me that it just suddenly ignored the config in the profile. I will give it a try tomorrow once I have access to it and update here. I’m using 4.14 version by the way.
Also, out of interest, why are you using multiple profiles for the statically assigned IPs, rather than adding the NIC devices with static IP directly to the container?
Hey @tomp , looks okay now. No idea what happened but after bringing up the server again /var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.leases is empty. Starting the VM in LXD, I can now see the static leases properly. Also, these are not containers but VMs. I cannot reproduce this on containers.
Regarding your question, I used to copy out the VMs to another LXD to conserve storage and copy back in when I need it. Profiles help me to persist the ip and the limits prior to starting after copy. Or maybe I don’t know an easier way as I just started learning/using. By the way, maybe a bit off topic from my original one. I have tried and confirm in the documentation that ipv4.address is not part of parameter for macvlan. I wonder whether there is a reason why its ommited? Thanks in advance.
This will copy the profile’s eth0 config into the VM’s own config and then update its ipv4.address setting, so that has its own config. This avoids needing to create a profile for each instance.
I was wondering if perhaps the use of profiles was causing this issue as I was not able to reproduce the issue. I’ll try with VMs.
The macvlan NIC type doesn’t use LXD’s dnsmasq process (as macvlan NICs cannot communicate with the LXD host) and so there is no way to setup a static DHCP lease via the ipv4.address setting.
Thanks @tomp. I will let you know if I manage to reproduce it. So far, I encountered it only once. I was thinking as well if I may have passed a wrong interface name cause this VM seems to change interface name. from eth0 to enp5s0 e.g.
Thats expected I’m afraid. We have no way to pass the specified name property (as opposed to the device name) into the VM (like we can with containers). So the actual interface name is derived from the virtual PCI slot. The PCI slot is static and is derived from the order of the VM’s devices (NICs go first, followed by disk and then other devices, ordered by device name).
Before the lxd-agent has started inside the VM, LXD tries to ‘guess’ what the IPs will be (by looking at the dnsmasq leases file and the host’s ARP cache and trying to match on the NIC’s MAC address), and uses the device’s name from the config to give them context. This is why it changes once the VM has started and the lxd-agent is running inside the VM. This is useful when running VMs that don’t have an lxd-agent (like Windows right now) as often the IPs are correct.
But this doesn’t affect the output of lxc network list-leases lxdbr0
Thank you so much for the patience and help. I really like this community cause people are very helpful and supportive. I am enjoying LXD and helped me a lot on my work. Thanks.