[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Systemd predictive network interface names for Stretch

Sounds good to me too- I haven't come to any other conclusions that will sanely work by default without introducing more complexity in instance initialization logic (whether that is part of cloud-init or otherwise). I was hoping we had a better solution via systemd-networkd.

Zach Marano

On Tue, Jun 6, 2017 at 1:22 PM, kuLa <kula@kulisz.net> wrote:
On 2017-06-02 16:53:24, Emmanuel Kasper wrote:
> >> Generally, to the debian-cloud folks, what are your thoughts here for
> >> Debian cloud images. The possibility that PCI devices can change is always
> >> on the table and we shouldn't assume it can't happen in any given
> >> virtualization environment.
> I can't speak for all cloud providers but bootstrap-vz disables
> persistent nic device names via net.ifnames=0 boot param
> see :
> https://github.com/andsens/bootstrap-vz/blob/f71eac2c390e67ebac4e237d937481ae1909e800/bootstrapvz/common/tasks/grub.py#L229
> this seems a good thing if the platform you build is not the one you run
> I do the same for Vagrant Virtualbox images, as I build with qemu for a
> Virtual Box target and nic pci position on bus is different

A few days back we had had discussion about this subject on IRC in regards of
AWS images and I think we reached conclusion to use **net.ifnames=0** to sort
it out (at least for now).

So probably the same should be done for GCP images and in regards of
discrepancies between default Debian image and Cloud image we just need to
document it and go with it as without fixing this issue IMO images are partly

|_|0|_|                                                  |
|_|_|0|                  "Panta rei"                     |
|0|0|0|             -------- kuLa --------               |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3

Reply to: