[HorizonXP]

Alex this looks great and likely addresses a lot of the problems I had with cloud-config. I was one of those with a Bash script that I used to generate multiple files, so this is great.

My biggest issue so far is CoreOS' naming of Ethernet interfaces on VMWare ESXi. It always uses some eno* name for each interface. I have a unique case where each VM I spin up has up to 10 interfaces.

I've solved this by adding net.ifnames=0 to my grub.cfg. It requires that I reboot the machine at least once to get it to take.

If I could have predictable interface names using Ignition, then I'm set!

[jsmthrowaway]

> My biggest issue so far is CoreOS' naming of Ethernet interfaces on VMWare ESXi. It always uses some eno* name for each interface. I have a unique case where each VM I spin up has up to 10 interfaces.

That's a systemd decision, not CoreOS, and also impacts the 7.x series of RHEL derivatives and anything that uses systemd > v197, really. Your way is one of three to revert it.

https://www.freedesktop.org/wiki/Software/systemd/Predictabl...

[HorizonXP]

Ah, fair enough. But it looks like that introduces another problem. When you spin up a VM in ESXi, it generates a new MAC address for each interface. So it would be great to create systemd .network files that bind to those MAC addresses. Except you don't what MAC addresses you need to match against. The only flow I see working is:

1) Create a VM with your interfaces, but don't boot it. 2) Take the MAC addresses and enter them into your .network files, created via cloud-config/Ignition 3) Mount the cloud-config/Ignition file to your VM and boot

Which is a bit painful to do manually when you have 10 VMs, with 5-10 interfaces each. I'd love to automate this, and if you happen to have a suggestion here, I'd really appreciate it.

Edit: Oh, and when I said it had an eno* number, it's more like eno16777736, which is not very predictable at all.

[wmf]

You don't have to match against MAC addresses, although there's virtually no documentation about how to do it any other way. In the pre-systemd past I've successfully created udev rules that match PCI slots so that the configuration does not depend on MAC addresses. It looks like the same thing should be possible (with trial and error) with path globbing in systemd.

[justinsaccount]

Are you talking about things like eno16777736 ? it's a vmware issue...

http://serverfault.com/questions/636621/why-is-my-eth0-calle...

[HorizonXP]

Yes, precisely. The comment below identified one of 3 possible routes to turn off the naming, one of which I'm using (net.ifnames=0 in the kernel config).

If I could find a better way to match the interfaces, it would be fantastic.

[otterley]

Why do you need predictable interface names if you're using DHCP?

[HorizonXP]

I am not using DHCP.

[otterley]

You should; it'll solve your problems.

[seanp2k2]

Yes, use DNS for everything, then you can use IPv6 too, without having to remember those pesky long addresses!