https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
f
All the interfaces should already have static IP addresses; do you actually see them change?
Sorry, static MAC addresses
I'm about to join a meeting, but can look it up afterwards: the MAC address should be generated from a static host machine id, and the absolute path name to the VM directory.
You should be able to override it, if you want to specify your own, but the current one should not change over over time, even after factory reset
b
Well, you can’t have a static IP for the external interface rd0, the one connected to a local network. In order to have a static IP here one needs to allocate it from the available IPs on the local network.
I did have a change from .211 to .217 after firewall (which is also DHCP sever) upgrade
the MAC address should be generated from a static host machine id, and the absolute path name to the VM directory.
this will indeed create the same MAC address unless the VM is moved to another directory
But it actually makes sense - different directories, different VMs, different MACs
f
I've confirmed it, the MAC address is determine by host machine id, full path to the VM, and the index of the interface in your 
networks
section in 
lima.yaml
If you change your DHCP server, you will get a new IP address because the reservation for the MAC addresses are gone
b
Thus if I edit lima.yaml, the MAC changes, even for the same VM?
Understood about DHCP server - it issues addressed on first come, first served basis - unless it’s a static DHCP IP, of course. This is what happened, and I didn’t have static DHCP for that lima VM at the time
f
No, only if this order changes:
Copy code
networks:
  - lima: rancher-desktop-shared
    interface: rd1
  - lima: rancher-desktop-bridged_en0
    interface: rd0
I will have to double-check if we alway emit them in this order, but I would think so
b
if this is inside Lima VM, it wouldn’t matter much - unless someone unintentionally moves things around and reapplies the network settings or reboots the VM
f
You should never edit the 
lima.yaml
file. But I just realized that if you add additional networks in 
override.yaml
, then they will be defined first, so take over the index from 
rd1
(and 
rd0
). So maybe don't do that (why would you need more network interfaces?) 🙂
b
Doesn’t seem you’re using netplan, as I thought - and it doesn’t matter
f
It was always the intention in Lima and RD that MAC addresses are stable, and it looks like they are.
b
So maybe don’t do that (why would you need more network interfaces?)
I currently don’t, but for testing and other purposes, people might
It looks like even if the VM is completely recreated from scratch, the MAC will be the same
f
Yes, as long as it is stored in the same location again, and uses the same list of interfaces
I haven't tested it, but I also would expect that you can put this into `override.yaml`:
Copy code
networks:
- interface: rd0
  macAddress: "11:22:33:44:55:66"
- interface: rd1
  macAddress: "..."
b
What is the reason for using rd0 position in the file? Given that it always has the same position, does it contribute to uniqueness of the MAC address at all?
f
Not sure what happens if you then run RD without sudo, and don't have 
rd0
and 
rd1
b
I do run with sudo - I want the cluster to be accessible from other comps on my network, say for cases I run test driver on another machine to create a load
f
The reason is that 
rd1
always exists (if you allow sudo), because it is an internal shared network. 
rd0
is a bridged network, so if you are offline on a laptop, you may not have any external interface with an IPv4 address, in which case 
rd0
would not be created.
b
persistent/sticky DHPC worked as expected
f
So if 
rd0
was first, then the MAC address of 
rd1
would change if 
rd0
could not be created. This way both MAC addresses are stable (if they exist at all)
b
if you use names of interfaces instead of their position, you won’t have to worry about positions 🙂
f
Yeah, but the name depends on the interface you are bridging through
So when you are in the office and connected to ethernet, you may bridge through 
en0
, but when you are only on wifi you may bridge through 
en1
.
Oh, you mean the interface names...
b
Yup
f
I can't remember right now why we didn't do that
b
My premise is, if something can be edited, somebody will edit it. And change the order of things
if they change names, too bad, shooting themselves in the foot, so let them but changing the order always seems to be harmless
f
I think it was because they are optional, if you don't specify them in 
lima.yaml
, then lima will assign 
lima0
, 
lima1
. etc to them. But we could still have used them for the MAC hash, so I don't know
b
Right… anyways, my problem seems to be solved, and I’ve learned a few things thanks to you 🙂
f
I don't think we will change anything, as it would change MAC addresses for everyone when they upgrade
b
Yes indeed, and it’ll be breaking change, so you might want to avoid this
f
So what we have seems "good enough" and you can override by explicitly specifying a 
macAddress
if you need to
b
where do I specify the 
macAddress
?
f
In 
override.yaml
or 
default.yaml
Don't edit 
lima.yaml
please! 🙂
b
oh yeah - and this is exactly what I was asking for 🙂
f
b
I prefer not to edit anything unless I know what I’m doing
f
lima.yaml
is edited by RD, and we cannot guarantee that we won't break your changes. That's part of the reason I created the 
override.yaml
mechanism to keep user changes separate
b
I haven’t tested it, but I also would expect that you can put this into 
override.yaml
That’s exactly where I expected it to be, thank you for confirming!
f
The thing I had to look up is if network settings are merged, and they are indeed, based on interface name
Some settings are simply concatenated
b
While it’s beyond the current conversation topic, it seems like I can also add interfaces (no need for now) in 
override.yaml
, is it the case?
Some settings are simply concatenated
you probably mean merged with user settings having a higher priority… but I’m nitpicking 🙂
f
I mean concatenated 😛 E.g. provisioning scripts are combined from 
override
, 
lima
, 
default
in that order, and there is no merging because they don't have a shared key.
✅ 1
Mounts and networks can merge settings based on a shared key, so you can modify a mount in 
override
instead of creating a new one.
DNS settings are taken from the highest priority source, so if they are defined in 
override
, then settings in 
lima
and 
default
are ignore because it doesn't make sense to combine nameserver lists
So every setting may have a specialized behaviour how the final value(s) are determined
b
OK, good to know
f
Thank you for coming to my TED talk! 😄
😆 1
19 Views
Open in Slack
PreviousNext
Powered by