Согласно комментариям в Xen's network-bridge скрипт, процесс запуска моста с внешним интерфейсом eth0 выглядит следующим образом:
# Creates the bridge
# Copies the IP and MAC addresses from eth0 to veth0
# Renames eth0 to be peth0
# Renames veth0 to be eth0
# Enslaves peth0, veth0 to bridge
ПРИМЕЧАНИЕ: на самом деле это не похоже на то, что делает сценарий. На последнем шаге похоже, что он фактически порабощает peth0 и vif0.0 мосту, но я не знаю, важно ли это для моего вопроса.
Зачем тасовать? Разве это не эквивалентно переименованию veth0 в peth0, а затем из eth0 в veth0? Я думаю, что упускаю что-то важное, но я этого просто не вижу.
Ваша схема переименования не будет работать, потому что peth0 является "Физическим eth0", и по-вашему, в итоге peth0 являясь виртуальным интерфейсом.
Честно говоря, я считаю, что мосты в Xen - сплошные шары, и я просто использую встроенную настройку мостовой конфигурации ОС (/etc/network/interfaces делает это очень просто), а затем просто укажите в конфигурации domU, к какому мосту подключиться. Я также называю все свои мосты значимыми именами (что помогает, потому что у нас везде есть VLAN, и все они тоже значимо названы).
Цель состоит в том, чтобы поддерживать IP / MAC «eth0» для ОС хоста, но не связывать физический интерфейс с конкретным IP. Это позволяет гостю не нуждаться в NAT для своей сети.
Игра с переименованием призвана свести к минимуму время простоя сети, уменьшить количество вещей, которые могут пойти не так в последнюю минуту, и предоставить простой способ отступить, если что-то пойдет не так.