VMs получают идентичного дюйм/с

Я часто выполняю несколько экземпляров Сервера Ubuntu в VirtualBox VM для тестирования различных вещей. Я обычно устанавливаю Ubuntu однажды и затем клонирую VM так много раз, как я должен. Я использую Соединенные мостом Сети в VirtualBox и получаю динамический IP от моего маршрутизатора. VirtualBox имеет способность рандомизировать MAC-адрес виртуального NIC. С 16,04 это хорошо работало: Установка + Клон + Рандомизирует MAC =, каждый экземпляр получает свой собственный уникальный IP.

Это больше не работает в 18,04. Я не понимаю, почему, но даже когда я изменяю MAC, все клоны всегда получают тот же IP-адрес. (Мой маршрутизатор, кажется, думает, какой бы ни экземпляр, загруженный в последний раз, владеет IP.)

Кроме того, когда я изменяю VMs на статического дюйм/с с помощью netplan следующим образом...

$ cat /etc/netplan/01-netcfg.yaml

network:
    version: 2
    renderer: networkd
    ethernets:
        enp0s3:
            dhcp4: no
            addresses: [192.168.1.28/24]
            gateway4: 192.168.1.1
            nameservers:
                addresses: [192.168.1.1]

... NIC заканчивается с двумя дюйм/с - статический адрес, как который я присваиваюсь, и исходный динамический IP, так:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:dd:e5:ea brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.28/24 brd 192.168.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet 192.168.1.154/24 brd 192.168.1.255 scope global secondary dynamic enp0s3
       valid_lft 86383sec preferred_lft 86383sec
    inet6 fe80::a00:27ff:fedd:e5ea/64 scope link
       valid_lft forever preferred_lft forever

Я погуглил повсеместно и не могу понять это. Я предполагаю, что это может иметь некоторое отношение к облаку-init, но раз так я не могу выяснить, что делать с этим.

Цените любую справку!

0
задан 15 September 2018 в 22:45

1 ответ

Я видел это много времен недавно, таким образом, я на данный момент просто предполагаю, что Вы поражены тем же и обеспечиваете его как ответ. Если это не Ваш случай, по крайней мере, он мог бы помочь другим.

Компоненты к проблеме:

  • клонируйтесь система после начальной загрузки его (никогда не должен делаться, по моему скромному мнению),
  • networkd

Теперь то, что происходит, - то, что на первой начальной загрузке systemd генерирует /etc/machine-id и впоследствии networkd будет использовать это для создания клиентского идентификатора в его запросах DHCP.

Это будет предпочтительным уникальным идентификатором для обслуживания дюйм/с и поэтому всех машин, клонированных с тем же /etc/machine-id будет конфликтовать.

Существуют больше, чем то, что сделано на первом boot/init, который является причинами, необходимо, по моему скромному мнению, запустить с чистых облачных изображений плюс развертывание процедуры. Но на данный момент, удостоверьтесь /etc/machine-id удален. Это генерирует новый на начальной загрузке, и системы могут дифференцироваться сервером DHCP.

0
ответ дан 27 October 2019 в 23:15

Другие вопросы по тегам:

Похожие вопросы: