可預測的網路介面名稱中斷 vm 遷移
/etc/networking/interfaces
使用“可預測的網路介面名稱”時如何重置?早於 15.10 的 Ubuntu 版本使用網路適配器名稱,例如:
eth0
eth1
eth2
更換網卡或將 vm 移動到新的虛擬機管理程序會導致 Linux 增加介面編號。刪除
/etc/udev/rules.d/70-peristent-net.rules
將使 Linux 重用eth0
。Ubuntu 15.10 和更新版本使用“可預測的網路介面名稱”。網路適配器名稱來源於 mac 地址。
ens3
ens32
ens192
遷移 vm 時,網路不會啟動,因為
/etc/network/interfaces
仍然引用舊的不存在的網路適配器。# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto ens32 iface ens32 inet dhcp pre-up sleep 2
重置 /etc/network/interfaces 文件的最佳方法是什麼?
我需要在關閉 vm 並遷移到新的虛擬機管理程序之前執行此操作,因為我正在使用打包程序根據廚師/便當黃金映像製作自動化黃金映像。
我發現刪除 /etc/network/interfaces 不起作用,因為遷移後下次啟動時不會自動重新生成文件。
我嘗試編輯我的 grub 文件以恢復為“eth0”命名約定。雖然 /etc/network/interfaces 確實引用了舊名稱 (eth0),但 vm 不會獲得 ip,並且任何重新啟動都會導致 vm 使用新的命名約定。此外,我發現 systemd 將始終優先,除非我可以保證
biosdevname=0
永久保留在 grub config中。不知道如何永久應用這個GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 bios.devname=0"
如果可能的話,我寧願不使用 cloud init 或使用任何啟動後腳本,因為我寧願保持黃金映像盡可能乾淨。
當然,這是雲提供商(Azure、AWS、RackSpace、Openstack)在導入 vm 時已經解決的問題。我不可能是第一個嘗試使用可預測的網路介面名稱遷移虛擬機的人。
在關閉和遷移 vm 之前,我嘗試過執行這些命令
apt-get remove biosdevname -y; ln -s /dev/null /etc/systemd/network/99-default.link;
我發現當我遷移虛擬機時,
/etc/network/interfaces
仍然ip address
指的是ens32
我放棄了嘗試乾淨地做到這一點,並提出了以下技巧。通過在關閉 vm 和遷移之前執行以下腳本,vm 將在開機時將 eth0 作為網路適配器。
ln -s /dev/null /etc/systemd/network/99-default.link; echo '# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet dhcp pre-up sleep 2' > /etc/network/interfaces sed -i.bak 's/GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 bios.devname=0 quiet"/' /etc/default/grub update-grub apt-get remove biosdevname -y || true;
嚴格來說,
apt-get remove biosdevname
不是必需的,因為預設情況下該軟體包未安裝在 ubuntu 16.04 上。此外,由於未安裝 biosdevnamebios.devname=0
,GRUB_CMDLINE_LINUX_DEFAULT
因此不需要添加。如果將來安裝了 biosdevname,它確實可以防止網路中斷。
當然,這是雲提供商(Azure、AWS、RackSpace、Openstack)在導入 vm 時已經解決的問題。
我認為 OpenStack 使用 cloud-init、ConfigDrive 格式,並提供與 VM 硬體相匹配的網路配置。資料來源:
- https://bugs.launchpad.net/cloud-init/+bug/1577747
- https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html?highlight=configdrive
- https://ask.openstack.org/en/question/63105/ways-to-inject-networking-configuration-on-instance-boot/
- https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/installation-and-configuration-guide/#setting_up_cloud_init
如果您排除首次啟動腳本,則有一個明顯的答案。
以前幾乎可以保證配備單個乙太網卡的主機只有一個“eth0”介面。有了這個新方案,管理員現在必須首先檢查本地介面名稱是什麼,然後才能對其呼叫命令,而以前他很有可能“eth0”是正確的名稱。
我不喜歡這個,如何禁用它?
你基本上有三個選擇:
- 您禁用固定名稱的分配,以便再次使用不可預測的核心名稱。為此,只需為預設策略屏蔽 udev 的 .link 文件: ln -s /dev/null /etc/systemd/network/99-default.link
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
切換回舊的持久介面名稱不是記錄的選項之一。
另一種選擇是預設啟用網路介面的設置,無論它們的確切名稱如何。我認為 NetworkManager 預設支持這個。 systemd-networkd 也可以被告知這樣做。
一旦您有多個用於 VM 的網路設備,它們可能無論如何都需要特定的配置……
在 VM 之外,NetworkManager 風格的方法有一個明顯的優勢:一台 PC 可能有多個網路介面,可能是不同類型的,只有一個連接。例如,這可以在一些高級主機板上看到,或者在第一個網路介面沒有按預期工作並且在某個時候安裝了第二個介面的系統上看到。